Simplify and rename macro API #11803
Conversation
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:
* Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to
BasicMacroExpander, etc. I think "procedural macro" is the right
term for these now, right? The other option would be SynExtExpander
or something like that.
* Stop passing the SyntaxContext to extensions. This was only ever used
by macro_rules, which doesn't even use it anymore. I can't think of
a context in which an external extension would need it, and removal
allows the API to be significantly simpler - no more
SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
|
I wonder if it's possible to completely extract the public ext API from the syntax crate. |
|
The surface of the ext API is pretty huge since it includes all of the AST, codemap, parser, and probably a bunch of utility stuff. The parts that could be removed would include all of the builtin procedural macros, possibly the pretty-printer and some random stuff like the crateid module. |
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:
* Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to
BasicMacroExpander, etc. I think "procedural macro" is the right
term for these now, right? The other option would be SynExtExpander
or something like that.
* Stop passing the SyntaxContext to extensions. This was only ever used
by macro_rules, which doesn't even use it anymore. I can't think of
a context in which an external extension would need it, and removal
allows the API to be significantly simpler - no more
SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
|
It's probably pretty huge, but if procedural macros are ever to be stable, it needs to be clean and intentionally-designed, and separated from the rest of the compiler in a way that can be specced and standardized. |
|
e.g. the parser could be abstracted to just a few calls that input strings, and token-trees and outputs token-trees and ASTs; the AST can hopefully be wrapped in something opaque that doesn't expose the details. |
|
Having quoting that's reliable and sensible would help. (I'm not saying that the current quoting isn't this, but from what I've see, it seems to be rather a hack; I wrote something about a possible solution here, no idea if that's actually at all feasible/workable.) |
[`impl_trait_in_params`]: avoid ICE when function with `impl Trait` type has no parameters Fixes rust-lang#11803 If I'm reading the old code correctly, it was taking the span of the first parameter (without checking that it exists, which caused the ICE) and uses that to figure out where the generic parameter to insert should go (cc `@blyxyas` you wrote the lint, is that correct?). This seemed equivalent to just `generics.span`, which doesn't require calculating the spans like that and simplifies it a fair bit changelog: don't ICE when function has no parameters but generics have an `impl Trait` type
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:
BasicMacroExpander, etc. I think "procedural macro" is the right
term for these now, right? The other option would be SynExtExpander
or something like that.
by macro_rules, which doesn't even use it anymore. I can't think of
a context in which an external extension would need it, and removal
allows the API to be significantly simpler - no more
SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.