RPIT(IT)s "leak" internal implementation details of lifetime capturing via boundedness

[Y-jiji]

I tried this code:

trait A {
    type B<'a>;
}

struct Foo(u64);

impl A for Foo {
    type B<'a> = Bar<'a>;
}

struct Bar<'a>(&'a Foo);

trait X<Y: A> {
    fn method<'a, 'b>(&'a self, bar: Y::B<'b>) -> impl Iterator<Item=usize>;
}

struct Eric;

impl X<Foo> for Eric {
    fn method<'a, 'b>(&'a self, _bar: <Foo as A>::B<'b>) -> impl Iterator<Item=usize> {
        vec![1, 2].into_iter()
    }
}

struct Jack;

impl X<Foo> for Jack {
    fn method<'a, 'b>(&'a self, _bar: Bar<'b>) -> impl Iterator<Item=usize> {
        vec![1, 2].into_iter()
    }
}

fn main() {}

I expected to see this happen: implementation of X<Foo> on Jack compiles without error

• As you can see, Bar<'a> and <Foo as A>::B<'a> are exactly the same type.
• Therefore, implementation of X<Foo> on Jack and Eric should have identical behavior.
• Implementation of X<Foo> on Eric compiles.

Instead, this happened: implementation of X<Foo> on Jack gives the following error

error[E0195]: lifetime parameters or bounds on method `method` do not match the trait declaration
  --> gat-borrow-checking-bug.rs:28:14
   |
14 |     fn method<'a, 'b>(&'a self, bar: Y::B<'b>) -> impl Iterator<Item=usize>;
   |              -------- lifetimes in impl do not match this method in trait
...
28 |     fn method<'a, 'b>(&'a self, _bar: Bar<'b>) -> impl Iterator<Item=usize> {
   |              ^^^^^^^^ lifetimes do not match method in trait

error: aborting due to 1 previous error

Meta

rustc --version --verbose:

rustc 1.85.1 (4eb161250 2025-03-15)

Using the nightly version, it still doesn't work

rust version 1.88.0-nightly (74509131e 2025-04-29)

[Y-jiji]

@rustbot label +T-compiler +T-trait

[rustbot]

Unknown labels: T-trait

[Y-jiji]

@rustbot label +T-compiler

[Y-jiji]

@rustbot label +T-types

[Y-jiji]

@fmease @jieyouxu I'm willing to take some effort to fix this, but I'm absolutely a newbie in rust compiler. Can I get some help to get started?

[fmease]

Incidentally, this should be fixed by the recently opened PR #140523.

Edit: With that I mean the diagnostic.
Edit 2: Well, it prolly could be better in this specific scenario.