Account for missing turbofish in resolve errors

[estebank]

When encountering resolve errors caused by a missing turbofish having parsed as binops of types, emit a single error explaining the mistake clearly and silence redundant resolve errors.

error: can't compare two types
  --> $DIR/suggest-turbofish-parsed-as-comparisons.rs:11:41
   |
LL |     let _ = Arc::new(RwLock::new(HashMap<i32, i64>::default()));
   |                                         ^        ^ these are parsed as "less than" and "greater than"
   |
help: you likely intended to write type `HashMap` with type parameters, but type parameters in expression contexts require the use of the "turbofish" `::<>`
   |
LL |     let _ = Arc::new(RwLock::new(HashMap::<i32, i64>::default()));
   |                                         ++

Address #81816. We should reduce the verbosity of the output and not complain about too many arguments.

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 74 candidates
• Random selection from 17 candidates

[joshtriplett]

This is awesome!

I think it might be even more readable like this:

LL |     let _ = Arc::new(RwLock::new(HashMap<i32, i64>::default()));
   |                                         ^--------^ these are parsed as comparisons, not generics

(or however rustc / annotate-snippets normally formats multispans)

Because in practice, I think people are extremely unlikely to actually be trying to do comparisons, so the level of detail on that part isn't important. And one line rather than three would be nice, so that it's quicker to get to the more important help line telling you the real problem.

[estebank]

@joshtriplett what do you think of the current output? I am not necessarily a fan because the first part that I want people to look at is the <, but the label pulls the eye towards the >, but maybe that's offset by having fewer things to read in practice?

[joshtriplett]

@estebank I think it looks great. In practice, the most important thing here starts with "you likely intended to write type HashMap with type parameters", and ideally that would come first if we're sufficiently confident in it. That's much more important even than "can't compare two types" - the user wasn't trying to compare two types, they were trying to pass type parameters. The current output at least moves that higher.

I would love to see us checking if the result with inserted :: fully parses as a type-with-type-parameters, and if so, leading with something like 'type parameters in expression contexts require the use of the "turbofish" ::<>'.

[estebank]

I tend to follow the house rule on diagnostics of leading with "what the compiler expected" to complain about, followed by "this is what the user might have intended". Given that we have high confidence here, it might make sense to not follow that style, but the more we stray from the normal "error vocabulary", the higher the chance of people misreading a diagnostic while skimming, or forcing our users to have to think a bit more (having to categorize "which bucket does this error fall into?") before fully understanding it.

Edit: for context, this is what it looks like when the parser can't fully recover but identifies a likely missing turbofish:

error: comparison operators cannot be chained
 --> src/main.rs:2:18
  |
2 |     let _ = foo(A<B>)
  |                  ^ ^
  |
  = help: use `::<...>` instead of `<...>` to specify lifetime, type, or const arguments
  = help: or use `(...)` if you meant to specify fn arguments

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.