or-patterns: disallow in let bindings

[mark-i-m]

Blocked on #81869

Disallows top-level or-patterns before type ascription. We want to reserve this syntactic space for possible future generalized type ascription.

r? @petrochenkov

[mark-i-m]

Actually, I'm going to rebase this to not be based on the other PR... no need...

[petrochenkov]

I think this is indeed better blocked on #81869 because the logic here should be shared with fn parse_fn_param_pat.

[petrochenkov]

parse_fn_param_pat is not used for closures, so or-patterns in both function parameters and let bindings can be parsed with fn parse_pat_allow_top_alt and then reported as errors post-factum.

[mark-i-m]

parse_fn_param_pat is not used for closures, so or-patterns in both function parameters and let bindings can be parsed with fn parse_pat_allow_top_alt and then reported as errors post-factum.

Hmm.. so this made sense initially, but as I'm thinking about it, it seems that they are different... Specifically, in the case of let, I think we want to allow top-level or-patterns without a type, right? That requires first parsing the pattern and then looking for a Colon token after it... I think I can share the error generation itself, but not much more...

[petrochenkov]

I mean, in both cases we parse parse_pat_allow_top_alt and then look for a colon, except that it's mandatory in one case and optional in another.

[mark-i-m]

Hmm... I see. I'll take a closer look when I implement the changes in #79278 (comment)

[mark-i-m]

@petrochenkov I've pushed a commit which does a few things:

• Attempts to address your review comments.
• Changes let bindings to require no_top_alt, as per the Lang Team's request (Stabilize or_patterns (RFC 2535, 2530, 2175) #79278 (comment))
• Creates a new feature gate or_patterns_with_ty that allows the use of top-level or-patterns in let if there is not type annotation.

Please let me know what you think.

[petrochenkov]

I'm skeptical about the decision to not stabilize let P1 | P2 = E (without type annotation), but it's a conservative error so it's not a big deal.

What I would worry about more is nested | patterns neighboring type ascription in situations like

let b @ P1 | P2: T = E;

I'm not sure whether code like this is impossible with the currently implemented parsing priorities, this needs an investigation.
EDIT: In any case, the fix is to go through the top pattern recursively in search of or-patterns in fn parse_pat_before_ty, but without recursing into parentheses, tuples and other "closed" groups.

[bors]

📌 Commit e64138c has been approved by petrochenkov

[JohnTitor]

Failed in rollup: #82840 (comment)
Looks like we need a tweak to clippy.
@bors r-

[mark-i-m]

I think clippy should compile now.

[estebank]

@mark-i-m would you mind filing a ticket to change the unnecessary parens lint ahead of stabilization? I was recently touching this area and should be straightforward to make it not trigger for let (A | B) = C;.

We should probably have lints, in rustc or clippy for match expressions that can be reduced to matches! or irrefutable let bindings (I though we already had the later).

[mark-i-m]

@estebank I had thought I already fixed the lint in this PR, though I'm not sure why it was firing for clippy...

[estebank]

@mark-i-m ah! Interesting.

[petrochenkov]

@bors r+

[bors]

📌 Commit 402a00a has been approved by petrochenkov