Merge proc_macro_
expansion feature gates as proc_macro_hygiene
by jebrosen · Pull Request #52121 · rust-lang/rust (original) (raw)
I looked more closely at the individual gates and have some more thoughts on this. It ended up being a bit of a brain dump instead of any particular argument, so bear with me.
For a macro crate author: proc_macro_diagnostic
, proc_macro_qoute
, and proc_macro_span
are proc_macro
library features that a proc_macro crate must enable in order to use them. decl_macro
must be enabled to define decl macros. I think it's probably fair to require macro crate authors to list these out separately, but it will be frustrating if more changes happen to them.
For someone using a proc_macro crate, things are a lot muddier. use_extern_macros
is relatively understandable and hopefully stabilizing soon. proc_macro_path_invoc
appears to be a style choice and opt-in for the macro consumer. But the requirements for proc_macro_mod
, proc_macro_expr
, proc_macro_non_items
, and proc_macro_gen
are more likely imposed on a consumer crate because of something in the macro crate.
According to my understanding of the errors defined in libsyntax/ext/expand.rs and what activates them:
proc_macro_mod
- allows applying proc_macro attributes to a module.proc_macro_expr
- allows applying proc_macro attributes to a statement or expression.proc_macro_non_items
- allows expanding proc_macros to non-items (expressions, patterns, types, or statements). This certainly matters for bang-style/inline macros; I can't think off the top of my head what kind of attribute macro would need to do this.proc_macro_gen
- allows expanding proc_macros to anything containing a module or a macro definition.
Whether these gates are necessary or not is always (usually?) determined by the macro, but the consumer has to enable the features that support the macros they happen to use. For example, if Rocket's macros were all reimplemented today to perform exactly as the current plugin-based ones, I believe most application crates would need proc_macro_non_items
and proc_macro_gen
(in addition to use_extern_macros
and decl_macro
).
Side note: if use_extern_macros
stabilizes, I suspect consumer crates might not need decl_macro
in order to use a decl_macro
.