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]

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

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @joshtriplett
• [ ] @nikomatsakis
• [ ] @pnkfelix
• [ ] @scottmcm
• [ ] @tmandry
• [ ] @traviscross

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. See this document for info about what commands tagged team members can give me.

[joshtriplett]

We discussed this briefly in today's planning meeting.

Based on that discussion, I updated the Motivation section to include the concrete examples motivating this.

I'm also going to restart the proposed FCP, since team membership has changed since it was previously started.

@rfcbot cancel

[rfcbot]

@joshtriplett proposal cancelled.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @joshtriplett
• [x] @nikomatsakis
• [ ] @scottmcm
• [x] @tmandry
• [x] @traviscross

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. See this document for info about what commands tagged team members can give me.

[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]

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

[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:

• https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/141996

[safinaskar]

@joshtriplett , you didn't answer my question https://github.com/rust-lang/rfcs/pull/3697#discussion_r1957292486

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.

[joshtriplett]

Tracking issue: https://github.com/rust-lang/rust/issues/143547