Compiler suggesting unstable or-pattern in for loop

[ritobanrc]

When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature.

I tried this code:

    let a = vec![1, 2, 3];
    let b = vec![3, 4, 5];
    
    for foo, bar in a.into_iter().zip(b) {    }

As expected, the compiler gives an unexpected , in pattern error, because I forgot the parenthesis around (foo, bar). However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives".

error: unexpected `,` in pattern
 --> src/main.rs:5:13
  |
5 |     for foo, bar in a.into_iter().zip(b) {
  |             ^
  |
help: try adding parentheses to match on a tuple...
  |
5 |     for (foo, bar) in a.into_iter().zip(b) {
  |         ^^^^^^^^^^^
help: ...or a vertical bar to match on multiple alternatives
  |
5 |     for foo | bar in a.into_iter().zip(b) {
  |         ^^^^^^^^^^

Playground Link

While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this RFC.

While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in this situation (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a or-patterns syntax is experimental error, as expected, and including #![feature(or_patterns)] resolves the error.

Meta

I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them.

[nico-abram]

I would like to work on this, if possible

Would it just be only giving this suggestion if self.sess.gated_spans.is_ungated(sym::or_patterns) like here?

[jyn514]

@nico-abram that seems like the right approach :)

[nico-abram]

@rustbot claim

[nico-abram]

Looking at this more closely I'm not sure the fix is that simple, since some top level or patterns are stable and the suggestion is correct (And given) for those

The nested case seems to not get the suggestion (Which matches the comment for maybe_recover_unexpected_comma)

[nico-abram]

Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns

EDIT: I'm gonna try just propagating the GateOr into maybe_recover_unexpected_comma