Add expr202x macro pattern

[lf-]

This makes it possible to use inline_const (#76001) and let_chains
(#53667) inside macros' expr patterns in a future edition by
bifurcating the expr nonterminal in a similar way to pat2021 to
remove some backwards compatibility exceptions that disallow
const/let at the beginning of an expr match.

Fixes #84155 and relaxes the backward compat restriction from #80135 for
a future edition. This is not necessarily intended to go into 2021 as it I don't
think it's simple to write an automatic fix, and I definitely won't have time very
soon.

Here is a pathological case of #79908 that forces this to be an edition
change:

macro_rules! evil {
    ($e:expr) => {
        // or something else
        const {$e-1}
    };
    (const $b:block) => {
        const {$b}
    }
}
fn main() {
    let x = 5;
    match x {
        evil!(const { 5 }) => panic!("oh no"),
        _ => (),
    };
}

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[m-ou-se]

cc @rust-lang/project-edition-2021

[nikomatsakis]

Hmm, I'm in favor of the concept overall, but I'd like to have a bit of a "write-up" or something that brings together the required information. I don't quite remember, for example, what changes were required to the expr non-terminal and why.

[lf-]

Hmm, I'm in favor of the concept overall, but I'd like to have a bit of a "write-up" or something that brings together the required information. I don't quite remember, for example, what changes were required to the expr non-terminal and why.

Alright, that's entirely understandable! So it looks like the back compat thing for let chaining came from this comment discussion: #60861 (comment) and an associated fixme in the feature gate ui test introduced by that pr which passes here because this pr doesn't inflict the new behaviour on any edition yet. In other words, this one is here because of conservatism. But we can probably assume that someone out there has written a macro that depends on the exception in the current expression behaviour based on the next one's experience:

The other exception for inline const was because we got bitten by the issue that was proposed in the above discussion, but in the context of inline const. This exception got in because of #80135: it was needed to keep some macros on beta working, which expected the const keyword then some expression after, as I understand it based on my testing and reading examples.

The former exception was removed here since I was bifurcating anyway and could reserve it. The latter was because of inline const needing to have parens around it to be valid in macro invocations currently, which is odd and rather confusing (I didn't know about this trick to get it accepted by the parser until it was pointed out to me by a friend so I assumed it simply wasn't allowed. the error here is bad too). Macros taking :expr seem liable to hit an issue shaped like this whenever a syntax extension to expressions happens, as a form of inherent fragility, so it's probable some more exceptions like these might get introduced as extensions get added.

Does this need to happen now? Not strictly. It could happen later or never, at the expense of macros being a little more confusing: This PR was written while I was under the invalid impression you couldn't pass a const block to a macro as an expression, which I now know is possible with parens, but that fact was anything but discoverable. It would be good to resolve the syntax ambiguity to favour consistency in being able to put const { ...} anywhere an expression could go, including in macros, imo. I'm not super familiar with let chaining or how this applies in its case, although I'd be inclined to believe that a similar argument could be made.

[nikomatsakis]

I see. So the expr macro nonterminal is starting to diverge from the full set of expressions, is the point, in some specific cases (the ones you identified). Hmm!

[nikomatsakis]

Nominated for @rust-lang/lang discussion.

[bors]

☔ The latest upstream changes (presumably #84310) made this pull request unmergeable. Please resolve the merge conflicts.

[lf-]

force push: Fixed the merge conflict and also the feature gate using the wrong suggestion

[bors]

☔ The latest upstream changes (presumably #83386) made this pull request unmergeable. Please resolve the merge conflicts.

[pnkfelix]

Opened issue #86730 for lang team to discuss how we want to resolve this, as discussed in the 2021-05-11 lang team meeting (minutes, youtube).

[pnkfelix]

I believe the conclusion of the lang team is that we are not confident that the approach used in this PR is the exact right one we want to deploy, and so I propose we close this PR while we wait to resolve the questions raised in #86730.

[pnkfelix]

@rfcbot close

[rfcbot]

Team member @pnkfelix has proposed to close this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

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!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, 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.

[crlf0710]

Closing according to the fcp decision above.

[pnkfelix]

as noted by @traviscross elsewhere: Further action here is now gated on acceptance of rust-lang/rfcs#3531, "Macro matcher fragment specifiers edition policy".

[RalfJung]

That RFC has been accepted, so if someone wants to make progress here, you can help by picking up this PR, making sure it matches the RFC, and making it work with today's compiler. :)