Tracking Issue for RFC 3697 "Declarative `macro_rules!` attribute macros" (`macro_attr`)
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
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
macro_rules!attributes (https://github.com/rust-lang/rust/pull/144579) - Implement
unsafe attrrules and requireunsafeattribute syntax for them - 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_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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with RFC 3697 and the linked implementation PR, then review the remaining checklist items for unsafe attributes, documentation, styling, and stabilization. Use the rustc-dev-guide stabilization and documentation instructions plus the Style Guide. Done means the unchecked tracking items have been addressed and the unresolved questions have decisions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100