Macro fragment specifiers edition policy #3531
Conversation
traviscross
added
T-lang
Recently T-lang discussed the issue of macro matcher fragment specifiers, e.g. `expr`, falling out of sync with the underlying grammar of Rust. The consensus of the meeting was that it would be proper to set out a policy for how these divergences might be reconciled over edition boundaries. The purpose of this RFC is to memorialize the resulting consensus.
traviscross
force-pushed
the
TC/macro-fragment-policy
branch
from
e1cfc24
to
ee6e943
Compare
Since it had not been discussed, we had left unspecified whether running `cargo fix` would automatically replace fragment specifiers whose behavior had changed with the new fragment specifiers that had been added to preserve the old behavior. However, this is probably the right thing to do, so let's go ahead and specify it. (Thanks to Ralf Jung for asking about this.)
In the meeting, we did not discuss whether the new fragment specifiers that preserve the old behavior should be added to all editions or only to the new edition, and accordingly, we did not discuss when these should be added. In keeping with our general policy of working to minimize differences between editions, it would seem to make sense to add these fragment specifiers to all editions. Given that, to provide people with the most time possible to prepare for the new edition, it would make sense to add these as early as possible and no later than when the new edition is released. Let's update the RFC to specify that. (Thanks to Ralf Jung for asking about this.)
|
Does it make sense to add |
One thing we could do, but probably won't, is to add a fragment specifier to all editions with the behavior of the specifier in the new edition. E.g., when releasing Rust 2024, we could add an `expr2024` fragment specifier to all editions. Let's add a section describing this and why it probably won't happen. (Thanks to deltragon for bringing this up.)
|
@deltragon: Thanks for bringing that up. That's now discussed in the RFC. |
There may be cases where it would not be practical to add the new fragment specifier to all editions. Let's describe this concession to practicality and specify the policy in such a way as to leave ourselves room for this. (Thanks to Niko Matsakis for raising this point.)
|
This great! Very sorry for it, but a minor bikeshed: should it be |
We had originally specified that, when a better semantically meaningful name could not be found, the new fragment specifier would be named by using the existing name with the identifier of the current edition added directly as a suffix, e.g. `expr2021`. However, reviewing RFC 430 and existing practice, we should probably instead use an underscore to separate the edition identifier, e.g. `expr_2021`. Let's update the RFC to specify that the underscore separator will be used, and let's add a section that discusses the other possible alternative choices. (Thanks to Nilstrieb for raising this point.)
|
@Nilstrieb: You raise a good point. Reviewing RFC 430 and existing practice, |
|
@traviscross Note: could you add a mention somewhere that there are cases where we can update a macro matcher within an edition, such as when we add brand new syntax that didn't previously lex (and thus couldn't be used in a macro)? |
joshtriplett
removed
the
I-lang-nominated
|
This looks great! This matches the policy we talked about, and gives a documented procedure for updating macro matchers in the future. @rfcbot merge |
|
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: 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. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot reviewed |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
In certain cases we may be able to update the fragment specifier simultaneously with adding new syntax without any risk of changing the behavior of existing macros. Let's add a footnote about that possibility in the background section, and let's add a paragraph in the policy that speaks to that. Clearly, in cases where we can prevent divergence, that's what we would do. (Thanks to Josh Triplett for raising this point.)
rfcbot
added
finished-final-comment-period
|
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. |
|
This RFC has been accepted and merged. This is a policy RFC, so there is no tracking issue. Thanks to all those who reviewed the RFC and provided useful feedback and suggestions. |
Recently T-lang discussed the issue of macro matcher fragment specifiers, e.g.
expr, falling out of sync with the underlying grammar of Rust. The consensus of the meeting was that it would be proper to set out a policy for how these divergences might be reconciled over edition boundaries.The purpose of this RFC is to memorialize the resulting consensus.
Rendered