Do not exclusively suggest ; when , is also a choice

[compiler-errors]

Fixes#96791

[rust-highfive]

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

[michaelwoerister]

I'm not quite sure this is an improvement in all cases. E.g. in the regression test:

fnmain(){let v = [12];//~^ ERROR expected one of `,`, `.`, `;`, `?`, `]`, or an operator, found `2`}

Does suggesting ? make sense, for example?

I think this is something for the diagnostics team to decide.
r? rust-lang/diagnostics

[michaelwoerister]

Also: Thanks for the PR, @compiler-errors! 😀

[compiler-errors]

Does suggesting ? make sense, for example?

It doesn't make sense type-wise, but this is parsing, so it's as valid as suggesting ? anywhere else, imo.

We could limit this to just mention , and ;, but then we'd probably get another bug report like #96791 that (rightfully) says "the ? token is also valid here, why aren't we reporting it?"

[compiler-errors]

@estebank do you have some time to look at this PR, or should I re-roll?

[compiler-errors]

r? diagnostics

[estebank]

I have to say, I'm not sure this is a net positive, but it's also not a net negative given the output changes are not really worse?

@bors r+

[bors]

📌 Commit 9d5c74e has been approved by estebank

It is now in the queue for this repository.

[compiler-errors]

@estebank: My thought process is that when , is one of the expected tokens alongside ;, then we're current parsing [ ..., and the heuristic of "semicolon is needed to end the statement" (which is what I think this logic is trying to account for) is probably incorrrect.

I could change this if you'd like to say something like ; or , since out of all the tokens, those are probably the most expected as I mentioned above.

[estebank]

@compiler-errors honestly, it's fine. What we'd ideally do is try to parse the rest of the expression and start parsing the following node to see which token would have helped, but to do that we need a lot of machinery that we don't currently have.