Declarative macro_rules! attribute macros
#3697
Conversation
joshtriplett
added
the
T-lang
joshtriplett
added
the
I-lang-nominated
|
Nominated as a follow-up to recent lang discussions about this. |
|
how will this work in // ok
macro main {
attr() ($func:item) => { make_async_main!($func) },
attr(threads = $threads:literal) ($func:item) => { make_async_main!($func, $threads) },
}
// ?
macro stub attr() ($func:item) {
make_stub_func!($func)
} |
|
Co-authored-by: Mads Marquart <mads@marquart.dk>
|
We had a @rust-lang/lang design meeting today on the set of macro RFCs. I've updated the RFC to incorporate all the feedback from that design meeting. Per the feedback in that meeting, I'm starting an FCP to start letting people register consensus for this RFC. @rfcbot merge |
|
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rfcbot
added
proposed-final-comment-period
Instead of specifying `impl ClassType for ...`, we instead parse the custom attributes `#[unsafe(super(...))]`, `#[thread_kind = ...]` and `#[name = ...]`. This is nice because: - It's more concise. - It more closely matches what we might end up with once it can become and attribute macro: rust-lang/rfcs#3697 - We need to parse the attributes anyhow to override derives: #267 (The extern_class! part of that issue is now resolved). - It makes it easier to change ClassType in the future without having to change the macro API as well. Additionally, this commit also adds incomplete support for generics, to avoid the framework crates depending on an internal macro, and it improves rust-analyzer support in extern_class! by having more relaxed parsing.
Many crates provide attribute macros. Today, this requires defining proc
macros, in a separate crate, typically with several additional dependencies
adding substantial compilation time, and typically guarded by a feature that
users need to remember to enable.
However, many common cases of attribute macros don't require any more power
than an ordinary
macro_rules!macro. Supporting these common cases wouldallow many crates to avoid defining proc macros, reduce dependencies and
compilation time, and provide these macros unconditionally without requiring a
the user to enable a feature.
I've reviewed several existing proc-macro-based attributes in the ecosystem,
and it appears that many would be able to use this feature to avoid needing
proc macros at all.
Rendered