[fmease]

This PR renders match $expr { ($pat if $expr) => $expr } syntactically legal under unstable feature guard_patterns. RFC 3637 does not forbid it, meaning the current implementation doesn't follow the specification.

The only reason why the current implementation rejects code like this is the fact that prior to the introduction of guard patterns in PR #133424 we already had parse error recovery & a custom diagnostic in place for, well, "accidentally parenthesized match arm patterns with guard". I guess the authors of #133424 did not want to regress the diagnostics here & so opted to leave that case alone (leaving a FIXME).

Furthermore, the error recovery code is hairy & verbose, so I'd like to see it simplified or gone. Fortunately, we can have the cake & eat it, too: We can allow match arm pat ($pat if $expr) if guard_patterns is enabled and continue to provide that custom-tailored diagnostic if it's not enabled (unless the code is cfg'ed out / dropped during expansion which is absolutely acceptable).

Note that we can't just query "is feature guard_patterns enabled" from inside the parser to know when not to emit the custom diagnostic because the answer depends on macro expansion. So instead, we entirely remove this logic from the parser and do it in compiler/rustc_ast_passes/src/feature_gate.rs where we have access to the list of all enabled features (& to Session for querying is_nightly_build).

Part of #129967.

_{(No LLM was or will be used by me during the entire creation process of this PR)}

[rustbot]

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, parser
• compiler, parser expanded to 77 candidates
• Random selection from 20 candidates