Repository navigation
Tracking Issue for RFC 3697 "Declarative macro_rules! attribute macros" (macro_attr) #143547
Description
Activity
Is an attribute macro allowed to recursively invoke itself by emitting the attribute in its output? If there is no technical issue with allowing this, then we should do so, to allow simple recursion (e.g. handling defaults by invoking the same rule as if they were explicitly specified).
As well as I understand, output of proc macros currently is not expanded. (See rust-lang/rfcs#2628 ). And I think this is a bug
Initial implementation: #144579
Reacted by Ryan Slawson, Aurorans Solis and CasperReacted by Daniel-Aaron-Bloom@safinaskar A macro_rules attribute re-applying itself seems to work just fine, and I have a test confirming that.
@safinaskar A macro_rules attribute re-applying itself seems to work just fine, and I have a test confirming that.
You mean that output of macro_attr is expanded? Cool! But then this is inconsistent with proc macros. Proc macros should be fixed, too
@safinaskar That sounds like a great thing for someone to work on, in another issue, along with the requisite RFC and crater runs. :)
Is an attribute macro allowed to recursively invoke itself by emitting the attribute in its output?
Macros can generally invoke themselves, and it shouldn't matter much how exactly they were defined, with a proc macro or with
macro_rules, and what macro kind they have.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.)
Many locations support only inert attributes and
cfg(_attr), but not macro attributes,macro_rulesattributes are macro attributes, so they shouldn't be usable in those locations as well.
Seefn supports_macro_expansionin the compiler for the list of specific locations.- added a commit that references this issue
on Aug 9, 2025 7 remaining items
- added a commit that references this issue
on Oct 3, 2025 - added a commit that references this issue
on Oct 12, 2025 - added a commit that references this issue
on Oct 18, 2025 - added a commit that references this issue
on Dec 21, 2025 - added a commit that references this issue
on Dec 29, 2025 - added a commit that references this issue
on Mar 27, 2026 - added a commit that references this issue
on Aug 24, 2026
This is a tracking issue for the RFC "Declarative
macro_rules!attribute macros" (rust-lang/rfcs#3697).The feature gate for the issue is
#![feature(macro_attr)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
macro_rules!attributes (Implement declarative (macro_rules!) attribute macros (RFC 3697) #144579)unsafe attrrules and requireunsafeattribute syntax for themrustfmtUnresolved Questions
Is an attribute macro allowed to recursively invoke itself by emitting the attribute in its output? If there is no technical issue with allowing this, then we should do so, to allow simple recursion (e.g. handling defaults by invoking the same rule as if they were explicitly specified).
Are there any places where we currently allow an attribute, but where implementation considerations make it difficult to allow a
macro_rulesattribute? (For instance, places where we currently allow attributes but don't allow proc-macro attributes.)Before stabilizing this feature, we should make sure it doesn't produce wildly worse error messages in common cases.
Before stabilizing this feature, we should receive feedback from crate maintainers, and potentially make further improvements to
macro_rulesto make it easier to use for their use cases. This feature will provide motivation to evaluate many new use cases that previously weren't written usingmacro_rules, and we should consider quality-of-life improvements to better support those use cases.Implementation history