Nested alias bounds are not considered when collecting free regions for liveness analysis

[adwinwhite]

I tried this code:

trait Bar {
    type BarAssoc: for<'a> Foo<FooAssoc<'a>: 'static>;
}

trait Foo {
    type FooAssoc<'a>
    where
        Self: 'a;

    fn assoc(&mut self) -> Self::FooAssoc<'_>;
}

fn overlapping_mut<T>(mut t: T::BarAssoc)
where
    T: Bar,
{
    let _a = t.assoc();
    let _b = t.assoc();
}

I expected to see this happen: compiles.

Instead, this happened:

error[E0499]: cannot borrow `t` as mutable more than once at a time
  --> counter_examples/indirect-outlive.rs:20:14
   |
19 |     let _a = t.assoc();
   |              - first mutable borrow occurs here
20 |     let _b = t.assoc();
   |              ^ second mutable borrow occurs here
21 | }
   | - first borrow might be used here, when `_a` is dropped and runs the destructor for type `<<T as Bar>::BarAssoc as Foo>::FooAssoc<'_>`

error: aborting due to 1 previous error

Meta

rustc --version --verbose:

rustc 1.98.0-dev (2026--6-26)
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.98.0-dev
LLVM version: 22.1.8

Analysis

Expression t.assoc() has type T::BarAssoc::FooAssoc. We don't have any item bound on FooAssoc but we can constraint it in the item bounds of BarAssoc.
So we should consider the alias bounds recursively for consecutive aliases, like in fn assemble_alias_bound_candidates_recur.

relevant code

cc @lcnr

[lqd]

cc @jackh726 due to #156027

[jackh726]

#156027 doesn't fix this (but it's certainly touches the same code!). This should be fairly trivial to fix. It's not actually the item_bounds call that's relevant, but rather the param_env bounds; the idea is that we need to "elaborate" the param_env:

When "fully elaborated", T: Bar leads to <T as Bar>::BarAssoc: Foo and for<'a> <<T as Bar>::BarAssoc as Foo>>::FooAssoc<'a>: 'static. And that second clause will do the job.

[adwinwhite]

Looks like the param env would get really large. I'll experiment with the idea to see the perf later.

[lcnr]

It's not actually the item_bounds call that's relevant, but rather the param_env bounds; the idea is that we need to "elaborate" the param_env:

this is not what we currently do in rustc and we explicitly recursively look at the item_bounds of rigid aliases and their self types, see fn assemble_alias_bound_candidates_recur.

Eagerly elaborating item bounds for the param_env may not terminate, e.g. consider

trait Trait<T> {
    type Assoc: Trait<Vec<T>>;
}

[jackh726]

The alias ty visited by FreeRegionsVisitor is not T:BarAssoc, it's <<T as Bar>::BarAssoc as Foo>::FooAssoc<'_>. So, I guess you're saying that we shouldn't be looking at the T: Bar in the param env, but rather recursing through to <T as Bar>::BarAssoc? Sure, that would work with the code as-written today, but doesn't work with how this has been refactored in https://github.com/rust-lang/rust/pull/156027/changes#diff-5d86c3fc35a603e984030459eb67d4870a975e53a460c331f15e48813ce8ce0eR27.

I think the point still remains that whether or not you elaborate bounds starting from the param env or if you start from the Self type of the alias, the underlying point I'm trying to make is that this is effectively an "extension" of the param_env.caller_bounds(). Once #156027 lands, this still fairly easy to do: you would add another loop through the additional bounds from the self type, like we do for the param_env.caller bounds(): https://github.com/rust-lang/rust/pull/156027/changes#diff-5d86c3fc35a603e984030459eb67d4870a975e53a460c331f15e48813ce8ce0eR546