impl_trait_in_bindings and pick-constraint region bounds

[nikomatsakis]

I'm working on #56238. In the process, I'm extending how impl Trait lifetime inference works -- in particular in scenarios involving multiple, unrelated lifetimes, such as impl Trait<'a, 'b>. The challenge here is that each region 'h in the hidden type must be equal to 'a or 'b, but we can't readily express that relationship in terms of our usual "outlives relationships". The solver is thus extended with a "pick constraint", written pick 'h from ['a, 'b], which expresses that 'h must be equal to 'a or 'b. The current integration into the solver, however, requires that the regions involved are lifetime parameters. This is always true for impl Trait used at function boundaries, but it is not true for let bindings.

The challenge is that if you have a program like:

#![feature(impl_trait_in_bindings)]

trait Foo<'a> { }
impl Foo<'_> for &u32 { }

fn main() {
  let _: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}

then we would wind up with pick '0 from ['1, 'static], where '0 is the region variable in the hidden type (&'0 u32) and '1 is the region variable in the bounds Foo<'1>. This is tricky because both '0 and '1 are being inferred -- so making them equal may have other repercussions.

For the time being, I've chosen to include some assertions that this scenario never comes up. I'm tagging a FIXME in the code with this issue number. I was going to create some tests, but owing to the ICE #60473 (not unrelated to this issue, actually), that proved difficult, so I'll just post comments in here instead.

[nikomatsakis]

Example test. An easy case is when they use named regions from in scope:

trait Foo<'_> { }
impl Foo<'_> for &u32 { }

fn bar<'a>(data: &'a u32) {
  let x: impl Foo<'a> = data;
}

[nikomatsakis]

Example test. A harder case is when we have inferred lifetime variables.

#![feature(impl_trait_in_bindings)]

trait Trait<'a, 'b> { }
impl<T> Trait<'_, '_> for T { }


fn bar<'a, 'b>(data0: &'a u32, data1: &'b u32) {
  let x: impl Trait<'_, '_> = (data0, data1);
  force_equal(x);
}

fn force_equal<'a>(t: impl Trait<'a, 'a>) { }

I expect this to compile because:

• the force_equal method forces the two '_ to be equal, so we effectively have impl Trait<'x, 'x>
• the hidden type is a tuple (&'0 u32, &'1 u32) where 'a: '0 and 'b: '1
• thus '0 and '1 must either equal 'x or 'static
• but 'x can be some portion of the fn body -- basically the scope of x

[lcnr]

The implementation of impl_trait_in_bindings have since changed to not use opaque types at all. This is now trivial to support and should get added as tests if none exist already. cc @compiler-errors

[mominul]

On 1.89.0-nightly (06-06-2025) the compilation statuses of the given examples are:

Test 1: Compiled successfully without errors.

#![feature(impl_trait_in_bindings)]

trait Foo<'a> { }
impl Foo<'_> for &u32 { }

fn main() {
  let _: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}

Test 2: Compilation fails with the following errors:

#![feature(impl_trait_in_bindings)]

trait Foo<'_> { }
impl Foo<'_> for &u32 { }

fn bar<'a>(data: &'a u32) {
  let x: impl Foo<'a> = data;
}

Errors:

error[E0637]: `'_` cannot be used here
 --> src/lib.rs:3:11
  |
3 | trait Foo<'_> { }
  |           ^^ `'_` is a reserved lifetime name

error: cannot capture late-bound lifetime in `impl Trait` in binding
 --> src/lib.rs:7:19
  |
6 | fn bar<'a>(data: &'a u32) {
  |        -- lifetime defined here
7 |   let x: impl Foo<'a> = data;
  |                   ^^

Test 3: Compiles successfully with warnings about dead codes.

#![feature(impl_trait_in_bindings)]

trait Trait<'a, 'b> { }
impl<T> Trait<'_, '_> for T { }


fn bar<'a, 'b>(data0: &'a u32, data1: &'b u32) {
  let x: impl Trait<'_, '_> = (data0, data1);
  force_equal(x);
}

fn force_equal<'a>(t: impl Trait<'a, 'a>) { }

@lcnr @compiler-errors What should be the next step be? Should I open a PR with these added ad test cases?

[lcnr]

test 2 should also use a valid lifetime identifier in the trait definition. With that, please open a PR adding these tests