Generic trait bound hides concrete type associated type

[LHolten]

I tried this code:

trait Tr<'x> {
    type Out;
    fn build() -> Self::Out;
}

struct Foo;

impl<'x> Tr<'x> for Foo {
    type Out = i32;
    fn build() -> Self::Out {
        42
    }
}

fn test<'x>() -> i32
where
    Foo: Tr<'x>, // commenting out this line fixes the error
{
    Foo::build()
}

I expect this to compile, but it gives the following error:

error[E0308]: mismatched types
  --> src/lib.rs:19:5
   |
15 | fn test<'x>() -> i32
   |                  --- expected `i32` because of return type
...
19 |     Foo::build()
   |     ^^^^^^^^^^^^ expected `i32`, found associated type
   |
   = note:         expected type `i32`
           found associated type `<Foo as Tr<'_>>::Out`
   = help: consider constraining the associated type `<Foo as Tr<'_>>::Out` to `i32`
   = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html

The code also works if the trait is made non-generic.

Meta

rustc --version --verbose:

rustc 1.86.0-nightly (ad211ced8 2025-01-07)
binary: rustc
commit-hash: ad211ced81509462cdfe4c29ed10f97279a0acae
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.6

same result on stable

[lolbinarycat]

probable duplicate of #24066 and #132959

[LHolten]

Yes it looks similar. This issue is a bit more specific in that the trait bound in the where clause is actually the correct trait bound, just without the associated type specified. The associated type should be known because the trait bound is on a concrete type.
So I think this issue could be solved even if only trait bounds in the where clause are considered (as long as the trait bound gets completed with the concrete associated type).
That said, I don't mind if this is closed as duplicate

[bravely-beep]

I agree with @LHolten ; the underlying cause may be the same as in the linked issues, but I can imagine a specialized bugfix potentially being applied for this case. Here the only difference between the specified bound and the actual implemented trait is an associated type, therefore there should be no ambiguity in trait resolution.