Declarative attribute/derive macros are not supported

[Zalathar]

• Tracking Issue for RFC 3697 "Declarative macro_rules! attribute macros" (macro_attr) rust#143547
• Tracking Issue for RFC 3698 "Declarative macro_rules! derive macros" (macro_derive) rust#143549

The Rust compiler has unstable support for using macro_rules! macros in attribute position or as derives, by prefixing individual rules with attr() or derive():

#![feature(macro_attr)]
#![feature(macro_derive)]

macro_rules! my_macro {
    attr()   ( $($tt:tt)* ) => { /* TODO */ };
    derive() ( $($tt:tt)* ) => { /* TODO */ };
             ( $($tt:tt)* ) => { /* TODO */ };
}

// Use as bang macro:
my_macro!(...);

// Use as attribute macro:
#[my_macro]
struct MyStructA;

// Use as derive macro:
#[derive(my_macro)]
struct MyStructB;

rust-analyzer hasn't added support for this macro_rules! syntax, so trying to use it results in a cryptic “expected subtree” error on the macro's name, not on the offending rules.

Furthermore, because rust-analyzer doesn't know how to expand declarative attribute/derive macros, any items declared by those expansions are not visible to r-a, making autocomplete and other IDE features much less helpful.

[Zalathar]

• See also #![feature(macro_attr)] expected subtree #20498.

---

I'm interested in using these features in more places throughout rustc itself, but the current lack of IDE support is too severe of a tradeoff.

I spent some time poking around in r-a to see what an implementation would look like. I was able to get parsing to work (by modifying the mbe crate), but so far I haven't been able to find how to get attribute/derive macros fed through the declarative-macro expander, and there's also some work to be done on making the expander only apply rules that match the kind of expansion being performed (bang, attr, or derive).

[ChayimFriedman2]

Generally we do not support so new features, but given that the lack of support severely impacts code using the feature, and that you want to use it in rustc, I won't resist.

I won't have time to implement the feature myself currently, though, and I also can't tell how much work this will be - I expect the assumption that attributes are proc macros is baked into a lot of places.

[ChayimFriedman2]

Sorry, commented on the wrong issue!