Description
This is a tracking issue for the RFC "Declarative macro_rules!
derive macros" (rust-lang/rfcs#3698).
The feature gate for the issue is #![feature(macro_derive)]
.
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 (currently deferred until after implementing Tracking Issue for RFC 3697 "Declarative
macro_rules!
attribute macros" (macro_attr
) #143547) - 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
-
Before stabilizing this feature, we should ensure there's a mechanism macros can use to ensure that an error when producing an impl does not result in a cascade of additional errors caused by a missing impl. This may take the form of a fallback impl, for instance.
-
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 usingmacro_rules
, and we should consider quality-of-life improvements to better support those use cases. -
Before stabilizing this feature, we should have clear public guidance recommending against pressuring crate maintainers to adopt this feature rapidly, and encourage crate maintainers to link to that guidance if such requests arise.