Declarative macro_rules! attribute macros

[joshtriplett]

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 would
allow 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

[joshtriplett]

Nominated as a follow-up to recent lang discussions about this.

[kennytm]

how will this work in macro form? or is rust-lang/rust#39412 decl_macro still a thing

// 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)
}

[joshtriplett]

@kennytm

how will this work in macro form?

macro is unstable and incomplete; if someone is working on it they can determine that. Your syntax proposal seems like a fine existence proof that it's possible to provide syntax for this.

[joshtriplett]

Nominated for consideration in a meeting to address any questions that arise.

[tmandry]

This RFC seems clear and straightforward to me, and the prior art in macro_rules_attribute and smol-macros makes it clear that this would be a useful feature out of the box. Thanks @joshtriplett for contributing this design.

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[traviscross]

@rfcbot reviewed

Thanks @joshtriplett for putting this together and putting it forward. The design makes sense and is appealing in its details, and it's clearly been put together carefully.

This will also give attribute macros access to the $crate mechanism to refer to the defining crate, which is simpler than mechanisms currently used in proc macros to achieve the same goal.

For our future selves, on this point, see also:

• Fix proc_macro::Ident's handling of $crate rust#141996

[safinaskar]

This will also give attribute macros access to the $crate mechanism to refer to the defining crate, which is simpler than mechanisms currently used in proc macros to achieve the same goal

Moreover, this will allow macros to access other crates, and this is very good. This is not solved by rust-lang/rust#141996

[safinaskar]

@joshtriplett , you didn't answer my question #3697 (comment)

In short: will declarative attribute macros be allowed on statements? (Procedural macros currently are not)

[joshtriplett]

@joshtriplett , you didn't answer my question #3697 (comment)

In short: will declarative attribute macros be allowed on statements? (Procedural macros currently are not)

My intention is exactly what's documented in the RFC: allowed everywhere an attribute is currently allowed. If, in the course of implementation, it becomes necessary to limit that further, we can do that and provide that update as part of the tracking issue. I've added a note to the unresolved questions section to evaluate that in the course of implementation.

[safinaskar]

@joshtriplett

Are there any places where we currently allow an attribute, but where
implementation considerations make it difficult to allow a macro_rules
attribute? (For instance, places where we currently allow attributes but don't
allow proc-macro attributes.)

I'm aware of one such place: statements. Proc macro attributes are not allowed in stable Rust, see this playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=388113d8f930565ec153d4453e2786c8 . But builtin attributes are allowed in stable Rust: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=2455967bcc1ecd203f44d7a0532fd800 .

Attributes on expressions always disallowed in stable Rust: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=68a4651e5619d11dbfa62ff5f84af066

[programmerjake]

Attributes on expressions always disallowed in stable Rust: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=68a4651e5619d11dbfa62ff5f84af066

nit: they're allowed in the input to an attribute macro, as long as the macro doesn't have them in its output.

#[my_attr_macro]
pub fn f() {
    let v = #[some_attr] S { a: 1 };
}

I use that extensively in fayalite

[tmccombs]

Why are proc macro atteibutes not allowed on statements? Would that same reason apply to declaritive attribute macros?

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.