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:

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.