Stream: t-compiler

Topic: What is `ext/`?

matklad (Sep 21 2019 at 18:41, on Zulip):

I am looking at ext/ and I am not sure what it does. I've tried commenting out it's method (item_use_list), but cargo check passed successfully after that. Is this something related to old syntax-based compiler plugins, which we want to remove anyway? Could we get rid of this thing or trim it down? ^^ cc @simulacrum, I think you've recently touched this code

simulacrum (Sep 21 2019 at 18:43, on Zulip):

I believe it's the helper code that's used by the built-in derives and macros for expansion...

simulacrum (Sep 21 2019 at 18:43, on Zulip):

Probably some of it isn't necessarily currently used though (not sure if I'd delete it; we might want it again)

simulacrum (Sep 21 2019 at 18:45, on Zulip):

@matklad hm, actually, that module might be entirely unused now

simulacrum (Sep 21 2019 at 18:47, on Zulip):

aha, no, I do get at least one error if I delete it entirely...

matklad (Sep 21 2019 at 18:47, on Zulip):

and if you commment it out, there's a bunch of usages

matklad (Sep 21 2019 at 18:48, on Zulip):

deriving/generic/ for one

matklad (Sep 21 2019 at 18:49, on Zulip):

I guess, long term, we want to transition built-in macros to token model and remove the thing?

simulacrum (Sep 21 2019 at 18:49, on Zulip):

hm, probably? It seems like most of it is basically just helpers -- probably replaceable with e.g. quote! or something like it from syn

simulacrum (Sep 21 2019 at 18:49, on Zulip):

I suspect it's probably mostly removable today

simulacrum (Sep 21 2019 at 18:50, on Zulip):

and it can definitely be decoupled from ExtCtxt I think

simulacrum (Sep 21 2019 at 18:51, on Zulip):

@matklad Do you ask for just "cleanup" or with some goal in mind?

matklad (Sep 21 2019 at 18:51, on Zulip):

just cleanup

simulacrum (Sep 21 2019 at 18:51, on Zulip):

yeah I'd probably leave it for now -- we can move it into src/libsyntax_ext though as free standing functions, though it's probably just needless churn

matklad (Sep 21 2019 at 18:52, on Zulip):

(but which probably would be required for long-term goal of syntax librarification: seems like making sure that everything uses token streams as much as possible should make extraction easier, as token streams are much simpler than AST)

simulacrum (Sep 21 2019 at 18:53, on Zulip):

I think a good first step to removing it would be to 'inline' portions of it -- particularly where it's pretty useless

simulacrum (Sep 21 2019 at 18:53, on Zulip):

e.g. most of the attr methods are just calling attr::<same name>(<same args>) which is largely unnecessary IMO

simulacrum (Sep 21 2019 at 19:01, on Zulip):

@matklad If you don't mind, I could take a look at some clean up to it?

matklad (Sep 21 2019 at 19:02, on Zulip):

@simulacrum sure, feel free do go ahead! I've just read this by accident: the thing I really want to do is to make sure that macro by example doesn't loose jointness info

matklad (Sep 21 2019 at 19:04, on Zulip):

(poking into various bits of libsyntax make me feel like those blind philosophers touching an elephant, but with a yak instead of an elephant)

Vadim Petrochenkov (Sep 21 2019 at 20:02, on Zulip):

The goal is to eventually migrate built-in macros in libsytnax_ext to token-based model and use some form of quote! for building their output (probably generating internal libsyntax TokenStream, rather than proc_macro::TokenStream, at least for a start.)
After that we'll be able to remove syntax/ext/, which kind of serves the same goal as quote!, but in AST-based world.

Last update: Jan 19 2020 at 10:50UTC