Type inference reports misleading diagonstics

[contrun]

I tried this code:

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

I expected to see this happen: I expect rust to tell me I should be more precise about 23u64 + xs.iter().sum().

fn main() {
    let xs: Vec<u64> = vec![1, 2, 3];
    
    // This works
    let temp: u64 = xs.iter().sum();
    println!("{}", 23u64 + temp);
    
    // This reports error correctly.
    let test = 23u64 + xs.iter().sum();
    println!("{}", test)
}

Instead, this happened:

error[E0284]: type annotations needed for `std::vec::Vec<u64>`
 --> src/main.rs:3:26
  |
2 |     let xs: Vec<u64> = vec![1, 2, 3];
  |         -- consider giving `xs` the explicit type `std::vec::Vec<u64>`, where the type parameter `u64` is specified
3 |     println!("{}", 23u64 + xs.iter().sum());
  |                          ^ cannot infer type for type `u64`
  |
  = note: cannot resolve `<u64 as std::ops::Add<_>>::Output == _`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0284`.
error: could not compile `playground`.

A method call variant of this problem is

pub trait Test<Rhs = Self> {
    type Output;

    fn test(self, rhs: Rhs) -> Self::Output;
}

impl Test<u32> for u64 {
    type Output = u64;

    fn test(self, other: u32) -> u64 { self + (other as u64) }
}

impl Test<u64> for u64 {
    type Output = u64;

    fn test(self, other: u64) -> u64 {
        (self + other) as u64
    }
}


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

The only difference is that self.test is a method call, while + is a binary operator.

rustc --version --verbose

rustc 1.43.0-nightly (158127853 2020-03-10)
binary: rustc
commit-hash: 15812785344d913d779d9738fe3cca8de56f71d5
commit-date: 2020-03-10
host: x86_64-unknown-linux-gnu
release: 1.43.0-nightly
LLVM version: 9.0

Related issue: #69214

[SkiFire13]

It gets even more misleading if you use xs before that addition. For example:

fn main() {
    let xs: Vec<u64> = vec![1, 2, 3];
    let ys: Vec<u64> = xs.iter().map(|i: &u64| i*2).collect();
    let _: u64 = 23u64 + xs.iter().sum();
}

This gives the following error:

error[E0284]: type annotations needed for `&u64`
 --> src/main.rs:3:39
  |
3 |     let ys: Vec<u64> = xs.iter().map(|i: &u64| i*2).collect();
  |                                       ^ consider giving this closure parameter the explicit type `&u64`, where the type parameter `u64` is specified
  |
  = note: cannot resolve `<u64 as std::ops::Add<_>>::Output == u64`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0284`.
error: could not compile `playground`.

This doesn't even report the line where the actual error is which is even more misleading. Imagine if there were several other lines between line 3 and 4.

Edit: Added explicit type to the map closure parameter to show it's still the same error.

[contrun]

@SkiFire13 Thank you for your additional information.
The root cause of this problem is that rust in unable to resolve u64 as Add<_> where _ is the rhs of +. Rust tries to call need_type_info_err which only accepts the error type u64 and the error span as parameters. Rust then tries to find all possible location of the error type in the body. When it finds a closure of type u64, it will report an error. When it finds a generics with generic parameter u64, it will report an error. These are all false positives cases.
I tried to solve this problem in PR #69456. Unfortunately the cases are too complicated. The function need_type_error_info takes care of not only error in this case. My PR will resolve the problem mentioned here, but it will bring in some other problems. Please refer to my PR for the detailed failed test cases. I basically have given up on this PR. I think the best way we can fix this is to pass the specific error type to need_type_info_err. This may require quite some refactor.