Tracking Issue for RFC 3697 "Declarative `macro_rules!` attribute macros" (`macro_attr`)

[joshtriplett]

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

• Implement the RFC (in progress)
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved 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_rules attribute? (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_rules to 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 using macro_rules, and we should consider quality-of-life improvements to better support those use cases.

Implementation history

[safinaskar]

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