Better diagnostics for : instead of -> in return type

[LeSeulArtichaut]

Follow-up to #77019

Originally posted by @bugaevc in #77035 (comment):

Would also be cool to emit this upon encountering

fn foo(_arg: i32): i32 {
    ...
}

which is how you'd define the return type in Scala and Kotlin.

[jyn514]

For reference, the current error is

error: expected `;` or `{`, found `:`
 --> src/lib.rs:1:18
  |
1 | fn foo(_arg: i32): i32 {
  |                  ^ expected `;` or `{`

error: aborting due to previous error

Playground

[estebank]

Pushed #78379 to use the regular "expected"/"found" error machinery, which will correctly say ->, ;, where or { can go there. That should be enough to direct people in the right direction (we would have to add a lot of checks to see if they meant ; or ->, which might be worth it 🤷‍♀️).

[pickfire]

I used tools with expected/found error machinery like in go and nix, but I still find rust explicit method better, after trying out those tools I get confused most of the time. I think it is only good as a fallback but specific error messages should still be available if possible.

[bugaevc]

For the reference, #77035 provides this nice specialized error for =>:

error: return types are denoted using `->`
  --> $DIR/fn-recover-return-sign.rs:3:8
   |
LL | fn a() => usize { 0 }
   |        ^^ help: use `->` instead

error: return types are denoted using `->`

[estebank]

@bugaevc for a while now I've been thinking that we should have a general typo checker for arbitrary positions. Such a check would allow us to give suggestions for for example match foo { _ -> {} } without us explicitly coding it. Is this something you would also be interesting to work on?

[bugaevc]

It wasn't me who implemented #77035 — that was @mibac138 🙂

That being said, I would be interested on working on something like that, yes! Perhaps you could describe how it could work and give me a few pointers?

[estebank]

In my mind, we could introduce a check in expect and expect_one_of to check for confusable tokens. We'd have a mapping of similar looking or close enough in the keyboard and compare them against what was expected. If there's a match, emit a specific error and return a non-error back up.

In expected_one_of_not_found we already perform something similar for closing delimiters, so the machinery to signal recovery is already in place. That can be used higher in the call stack to avoid producing further errors caused by misparses. Ideally we could pass in a list of expected tokens after the next one to do some sanity checks for the recovery not to kick in if it is too far from what we'd expect. (Basically, just bail if the code is too far gone from normal code.)