E0308 with complex types produces an unhelpful expected type vs found type note

[EsotericPyramid]

Code

// this does actually affect the diagnostic message 
// even though it doesn't show up, separate issue ig
mod really_really_really_long_module {
    pub trait FooBar {
        type Assoc: FooBar;
        type Wrapper<T>: FooBar;
    
        fn assoc(&self) -> Self::Assoc;
        fn wrap<T>(&self, value: T) -> Self::Wrapper<T>;
    }
}

use really_really_really_long_module::*;

fn bad_diagnostic<'a, T: FooBar>(value: T) -> <<<T::Wrapper<T> as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<<T::Assoc as FooBar>::Assoc> {
    value.assoc().assoc().assoc().wrap(value.assoc().assoc())
}

Current output

error[E0308]: mismatched types
  --> src/lib.rs:16:5
   |
15 | fn bad_diagnostic<'a, T: FooBar>(value: T) -> <<<T::Wrapper<T> as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<<T::Assoc as FooBar>::Assoc> {
   |                                               ----------------------------------------------------------------------------------------------------- expected `<<<... as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<...>` because of return type
16 |     value.assoc().assoc().assoc().wrap(value.assoc().assoc())
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `really_really_really_long_module::FooBar::Wrapper`, found `really_really_really_long_module::FooBar::Assoc`
   |
   = note: expected associated type `<<<... as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<...>`
              found associated type `<<<... as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<...>`
   = note: an associated type was expected, but a different one was found
   = note: the full name for the type has been written to '/Users/[username]/Library/Mobile Documents/com~apple~CloudDocs/Programs/rust_programs/bug_tests/target/debug/deps/bug_tests-ffcf3721a6d5102a.long-type-10445563434775290395.txt'
   = note: consider using `--verbose` to print the full type name to the console

Desired output

error[E0308]: mismatched types
  --> src/lib.rs:16:5
   |
15 | fn bad_diagnostic<'a, T: FooBar>(value: T) -> <<<T::Wrapper<T> as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<<T::Assoc as FooBar>::Assoc> {
   |                                               ----------------------------------------------------------------------------------------------------- expected `<<<... as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<...>` because of return type
16 |     value.assoc().assoc().assoc().wrap(value.assoc().assoc())
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `really_really_really_long_module::FooBar::Wrapper`, found `really_really_really_long_module::FooBar::Assoc`
   |
   = note: expected associated type `<<<... as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<...>`
              found associated type `<<<... as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<...>`
   = note: an associated type was expected, but a different one was found // add the actual types to this line OR don't elid them from the lines above
   = note: the full name for the type has been written to '/Users/[username]/Library/Mobile Documents/com~apple~CloudDocs/Programs/rust_programs/bug_tests/target/debug/deps/bug_tests-ffcf3721a6d5102a.long-type-10445563434775290395.txt'
   = note: consider using `--verbose` to print the full type name to the console

Rationale and extra context

Admittedly the example code is extremely artificial but I have actually ran into this a few times in actual code. Needless to say, getting an error that says 2 types which look identical but aren't with the only way to inspect them being going out of my way to look at a file with a ridiculously long name is very inconvenient and annoying.

Other cases

likely a separate issue, but moving FooBar outside of the module causes no eliding to take place even though the trait is printed exactly the same in the offending part of the message.

Rust Version

rustc 1.97.0 (2d8144b78 2026-07-07)
binary: rustc
commit-hash: 2d8144b7880597b6e6d3dfd63a9a9efae3f533d3
commit-date: 2026-07-07
host: aarch64-apple-darwin
release: 1.97.0
LLVM version: 22.1.6

Anything else?

No response

[chenyukang]

they are elided because the lenght exceeded the width of terminal.

rust/compiler/rustc_trait_selection/src/error_reporting/infer/mod.rs

Lines 2216 to 2223 in cb014fc

	if exp_s.len() > len {
	let exp_s = self.tcx.short_string(expected, long_ty_path);
	exp = DiagStyledString::highlighted(exp_s);
	}
	if fnd_s.len() > len {
	let fnd_s = self.tcx.short_string(found, long_ty_path);
	fnd = DiagStyledString::highlighted(fnd_s);
	}

@estebank do you think we need a tweak here for the case that types showed are identical?

[estebank]

I'm coincidentally looking into this right now, the repro is helpful. We already have Highlighter which is used for replacing lifetimes with numbered names in diagnostics (Foo<'1>). In #158992, I am making it so that it also has enough logic to shorten types while keeping all the lifetimes visible. I was already thinking about generalizing that behavior so that we could also tell the machinery "I care about this type, do what you can to keep it visible, while shortening the rest". That would certainly help here. It might require some rearchitecting, but should be possible to accomplish.

Note that you can use --verbose to have the compiler write the full path to the terminal.

Defending the current behavior a little, it is a tradeoff: there are some cases where the full type will be very convoluted (even more than the one shown here), and printing the whole thing by default would be very detrimental. That doesn't mean that we shouldn't improve our heuristics.

Edit: It doesn't seem like we need to implement a new Highlighter for types instead of lifetimes, we "just" have to add logic to handle projections in the highlighted cmp styled string builder, at least for this case. The other thing will still be generally useful, just not trigger in this case if we fix the other thing.

[EsotericPyramid]

Fair point. Completely brainfarted on --verbose even though its already in the error message.

One thought to maybe display these complex types more nicely without hiding important type information is to split the path across multiple lines, so
<<<T::Wrapper<T> as FooBar>::Assoc as FooBar>::Assoc as FooBar>::Wrapper<<T::Assoc as FooBar>::Assoc>
could become something like

<
    <
        <
            T::Wrapper<T> as FooBar
        >::Assoc as FooBar
    >::Assoc as FooBar
>::Wrapper<
    <
        T::Assoc as FooBar
    >::Assoc
>

Even outside this issue, this is just far more legible for very convoluted types and something I do personally. Rustfmt will split paths a little across lines but not to this extent so this isn't completely unprecedented.

[estebank]

@EsotericPyramid how do you feel about the following?

It's not the final state, but getting there.

I will look to change the primary span to only be Type::Assoc, and maybe shorten the length of the type in the span label pointing of the return type.

[EsotericPyramid]

I'm not sure I fully understand what changes you did, but from what I can tell it looks good. My only concern is that it looks like the generic parameters of the Wrapper associated type are being omitted from parts of the error message.

[estebank]

In the main "expected/found" note, the output now is shorter (without saving the path to the file) and highlights only the main point of contention. The note for the full name is still included because the label pointing at the return span still gets written to disk.

[estebank]

The latest version of the PR has the following output (it now accounts for divergences in the self-type, the trait, the trait params and the associated items' params.

[chenyukang]

The latest version of the PR has the following output (it now accounts for divergences in the self-type, the trait, the trait params and the associated items' params.

Looks great!
I will take another review on the code tomorrow.

[estebank]

Thank you for your review! Made me catch more things that I wasn't properly handling around parameters (the substs of <T as Foo<A>::Assoc<B> being [T, A, B] always bite me in the rear!) and the result looks much nicer than it would have otherwise.