Tracking Issue for updating expr macro fragment specifier for Rust 2024

[traviscross]

This is a tracking issue for updating the expr fragment specifier for Rust 2024 according to the policy described in RFC 3531:

• Macro fragment specifiers edition policy rfcs#3531

The feature gate for the issue is #![feature(expr_fragment_specifier_2024)].

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.

Steps

• Implement in nightly Rust 2024.
  • Update expr matcher for Edition 2024 and add expr_2021 nonterminal #123865
• Add test cases around nested macros spanning crates across different editions. For ideas, see this comment.
  • test: cross-edition metavar fragment specifiers #129755
• Update expr to match _.
  • [RFC] mbe: consider the _ in 2024 an expression #126697
• Implement migration lints.
  • migration lint for expr2024 for the edition 2024 #125627
• Remove edition gating on expr_2021 fragment specifier.
  • Make edition dependent :expr macro fragment act like the edition-dependent :pat fragment does #126700
• Stabilize new fragment specifier (expr_2021) in all editions.
  • Stabilize expr_2021 fragment specifier in all editions #129972
• N/A: Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • Add expr_2021 macro fragment specifier reference#1580
  • 2024: Update expr macro fragment specifier reference#1639
• Add documentation to the edition guide.
  • 2024: Add macro-fragment-specifiers. edition-guide#312
• Ensure ready for Rust 2024 stabilization.

Unresolved Questions

• Is there a reasonable semantically-appropriate name for expr_2021, or should we just call it that per the RFC?
  • Resolved, keeping expr_2021, see Tracking Issue for updating expr macro fragment specifier for Rust 2024 #123742 (comment).

Related

• Add expr202x macro pattern #84364
• Non-terminals, e.g. expr, have diverged between parser and macro matcher #86730
• Update expr matcher for Edition 2024 and add expr_2021 nonterminal #123865
• Avoid checking the edition as much as possible #125828
• Make edition dependent :expr macro fragment act like the edition-dependent :pat fragment does #126700
• [RFC] mbe: consider the _ in 2024 an expression #126697
• Make edition dependent :expr macro fragment act like the edition-dependent :pat fragment does #126700

cc @rust-lang/wg-macros @eholk @vincenzopalazzo

[eholk]

Do we also need item_2021, block_2021, etc.?

[Veykril]

It depends on what changes to the grammar have occured.

[ehuss]

Can someone please write down what changes are being done for this?

[eholk]

I haven't heard a clear answer, but it sounds like maybe supporting const { ... } in expressions is the only potential change.

[eholk]

Based on #86730, it looks like we also need to update expr to match let chains.

[eholk]

We might need to update item since we'll be requiring unsafe extern blocks in 2024, but it's not totally clear to me since I think you will be able to use unsafe extern in earlier editions, it just won't be required.

[eholk]

I guess the other potential change for expr is let chains. I spent some time working on them today, and it's not really clear to me what the right behavior is right now.

As I understand the RFC and #86730, we want to update expr in edition 2024 to match let x = y, even though that form is only allowed in the test position of an if or while loop.

This seems weird to me. Do we have expr match let chains unconditionally, and then expect the expansion will fail? Does expr only match a let chain if the macro is called in test position?

I think instead it'd make more sense to add a cond nonterminal what matches anything that can appear in the test position of an if or while loop.

[ehuss]

See also #126749 about whether or not $item should accept safe fn foo();, and if so should there be a separate $item_2021 for that?

[ehuss]

@compiler-errors pointed out that safe items won't be an issue, because $item already fails to parse safe fn foo(); because $item can already start with the safe token, so ignore my last comment.

[traviscross]

To confirm, the current understanding (now reflected in the issue description) is that the item fragment specifier does not need to be migrated.

This is because this is currently an error on stable Rust:

macro_rules! item {
    ($x:item) => {};
    ($(x:tt)*) => {};
}

fn main() {
    item!(safe fn foo() {});
}

...and because this is not an error on stable Rust:

macro_rules! item {
    ($x:item) => { 0u8 };
    ($(x:tt)*) => { 0u16 };
}

fn main() {
    let _: u8 = item!(unsafe extern {});
}

[traviscross]

@rustbot labels +I-lang-nominated

Should we name this new specifier expr_2015 rather than expr_2021?

[traviscross]

@rustbot labels -I-lang-nominated

We discussed in the call today. We'll name this expr_2021, as it is now.

And we'll want to get that new specifier stabilized soon, ahead of the edition.

[traviscross]

@rustbot labels +S-tracking-ready-for-edition

We reviewed this item in the edition call, and we confirmed this is now ready for Rust 2024.

Thanks to @eholk and @vincenzopalazzo for pushing forward on this important work.

[vincenzopalazzo]

Thank @traviscross manage and coordinate the work👌🏼