fix misleading type annotation diagonstics

[contrun]

This solves the method call part of issue #69455

[LeSeulArtichaut]

You may want to add a regression test for this. See the rustc book.

[JohnCSimon]

Ping from triage:
@contrun any updates on this?

[contrun]

@JohnCSimon As I explained in #69455 (comment), the problem is that my PR will eliminate some relevant error message in some cases. The current error messages obviously more informative. I can push a new commit to resolve the conflict and use --bless to change the error message to accommodate my PR. But I don't know if that is desirable.

[cramertj]

Yes, if you could --bless the output so that we can see what the changes are easily, that would be helpful!

[contrun]

@cramertj It is now ready for review. I added two field in the original struct. They are needed because I can not find any way to it without affecting existing error messages.

I added a target_span field so as to pin down the exact location of
the error. We need a dedicated field found_exact_method_call to
prioritize situations like the test case #69455. If we reuse
found_method_call, found_local_pattern will show up first. This is what rustc currently shows, which is a red herring.
We can not move found_method_call up, it is undesirable in various
situations. I tried it. Many tests failed.

[crlf0710]

r? @estebank

[estebank]

It would be amazing if we actually suggested <u64 as Test<u64>>::test(23u64, xs.iter().sum()), but that is beyond the scope of this PR.

[estebank]

The code looks ok to me. @contrun could you add tests for the cases you mention in your original comment would regress? I'm not sure I can see what they would be.

[contrun]

@estebank
Did you mean this one?

fn main() {
    let xs: Vec<u64> = vec![1, 2, 3];
    println!("{}", 23u64 + xs.iter().sum());
}

Unfortunately, my current PR does not solve that yet. This is because + is not parsed as a method call. It is parsed as a BinOp. I will submit a separate PR for that.

[estebank]

@contrun it is ok if this PR doesn't fix it, but having the test in the codebase helps us catch when an unrelated change either improves or degrades it. It also makes it easier for the reviewer to see the explicitly ignored cases.

That being said, now I see what the problem is and it shouldn't block this PR.

@bors r+

[bors]

📌 Commit 3ae974f has been approved by estebank