Compiler should not omit associated type in compile error message

[rhysd]

Environment

• Rust: Nightly 2019-10-07

Repro

1. Open https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=933123bb14852662962ab5bf5f2073c8
2. Click run

struct X<'a>(&'a mut i32);

impl<'a> Iterator for X<'a> {
    type Item = &'a i32;
    fn next(&mut self) -> Option<Self::Item> {
        Some(self.0)
    }
}

fn main() {}

Expected behavior

Compiler should raise an error with error message which explains why lifetime parameters are conflicting clearly

Actual behavior

It shows following error:

   Compiling playground v0.0.1 (/playground)
error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
 --> src/main.rs:6:9
  |
6 |         Some(self.0)
  |         ^^^^^^^^^^^^
  |
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the method body at 5:5...
 --> src/main.rs:5:5
  |
5 | /     fn next(&mut self) -> Option<Self::Item> {
6 | |         Some(self.0)
7 | |     }
  | |_____^
note: ...so that reference does not outlive borrowed content
 --> src/main.rs:6:14
  |
6 |         Some(self.0)
  |              ^^^^^^
note: but, the lifetime must be valid for the lifetime 'a as defined on the impl at 3:6...
 --> src/main.rs:3:6
  |
3 | impl<'a> Iterator for X<'a> {
  |      ^^
  = note: ...so that the types are compatible:
          expected std::iter::Iterator
             found std::iter::Iterator

error: aborting due to previous error

error: could not compile `playground`.

To learn more, run the command again with --verbose.

Confusing part is as follows:

  = note: ...so that the types are compatible:
          expected std::iter::Iterator
             found std::iter::Iterator

Compiler says 'expected' and 'found' are incompatible but they look the same. This is caused because associated type Item is omitted from error output of 'expected' and 'found'. Actually lifetime parameter in the associated type between 'found' and 'expected' are different but compiler hides them.

[estebank]

Associated items are predicates that are not carried around in the type, so by the time reach this we're not ferrying around the assoc types anymore. This will be hard to fix but very worthwhile.

[rhysd]

Thank you for the comment. I did not know the implementation under the hood.

It might be better to change the expected ... found ... error format in this case for avoiding confusion.
For example,

  = note: ...so that the associated types in std::iter::Iterator are compatible