Typoing "." instead of "," in a match produces confusing error messages

[ssbr]

Code

pub enum Foo {
    X, Y
}

pub fn invert(foo: Foo) -> Foo {
    use Foo::*;
    match foo {
        X => Y.
        Y => X,
    }
}

Current output

error: expected one of `(`, `,`, `.`, `::`, `?`, `}`, or an operator, found `=>`
  --> src/lib.rs:12:11
   |
12 |         Y => X,
   |           ^^ expected one of 7 possible tokens

warning: unused import: `Foo::*`

Desired output

I wish it would have tried error recovery by substituting "," where it saw a ".", which is a reasonable enough typo, so that it could give some kind of hint that maybe the previous line had been intended to be Y, not Y..

Rationale and extra context

No response

Other cases

Rust Version

I don't have rust installed locally, this was 1.86 in the rust playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1eb7427edcf893496f899d59f78ec1ff

Anything else?

No response

[Kivooeo]

Hm, it's interesting because it have recovery from ";"

11 |         X => Y;
   |           -- ^ this statement is not surrounded by a body
   |           |
   |           while parsing the `match` arm starting here
   |
help: replace `;` with `,` to end a `match` arm expression
   |
11 -         X => Y;
11 +         X => Y,

I will look into it

[chenyukang]

Hm, it's interesting because it have recovery from ";"

11 | X => Y;
| -- ^ this statement is not surrounded by a body
| |
| while parsing the match arm starting here
|
help: replace ; with , to end a match arm expression
|
11 - X => Y;
11 + X => Y,
I will look into it

emm, so sorry that I didn't notice you had a comment to take it.
I gave it a shot and came out with a fix.

[Kivooeo]

@chenyukang

No worries at all — glad you took a shot at it!

Just for context: the tricky part here is that . is a valid token, unlike ;, which makes typo recovery harder. In cases like this, . could also mean field access or method call, so detecting whether it was actually a typo is not straightforward.

Oh, you already fixed it and it seems more easy than I thought, heh

[chenyukang]

I think we might don't need to recover here, parser sometimes don't have enough context for a perfect recovery. giving proper suggestion will be good for users.