traits: Fix rigid alias liveness matching by Dnreikronos · Pull Request #160212 · rust-lang/rust

Dnreikronos · 2026-07-30T12:22:24Z

The ICE happens while borrowck computes liveness for an opaque return type with an associated type bound. In the repro, that bound looks like <impl Foo<'x> as Foo<'x>>::Out: 'static. The query passes unnormalized item bounds to extract_verify_if_eq, which expects rigid aliases with the next solver, and hits its debug assertion.

Item-bound collection already maps higher-ranked GAT arguments to the GAT's identity parameters. That means this query can compare the bound's self type directly with the identity alias. A bound on a nested projection, like the associated type in the repro, doesn't match the opaque itself and gets skipped. It doesn't tell us that the opaque is 'static.

For bounds that do match, we keep the outlives region unless it's still bound. For example, for<'b> Self::Assoc<'b>: 'b becomes a non higher ranker item bound Self::Assoc<'param>: 'param, so that param region still matters for liveness. With for<'b> Self::Assoc: 'b, the same associated type has to outlive every choice of 'b, including 'static. We handle that case directly.

I think this is a better fit for the query because it uses the work item-bound collection already did. It removes the matcher call from this path and keeps the shared matcher's rigidity checks intact. The separate call for function bounds stays, since it still needs to match against the alias's concrete arguments. There's no extra normalization in liveness.

The original repro covers the case that triggered the assertion: an item bound on a nested projection must be skipped when computing liveness for the opaque itself.

rustbot · 2026-07-30T12:22:30Z

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 74 candidates
Random selection from 17 candidates

jackh726

I'm not sure this is correct. Or, at least, I'm not sure this is the right fix. It certainly isn't principled.

I don't have time to fully dig in right now, but generally I would not expect us to arbitrarily be setting things as rigid. I'm not sure the correct fix, but the may even be in the use or definition of extract_verify_if_eq (or may not be).

View changes since this review

Dnreikronos · 2026-07-30T18:40:46Z

Yeah, that makes sense. I reworked this so liveness does not set aliases rigid anymore.

The ICE was in the path you pointed at, or at least right next to it: extract_verify_if_eq uses its local syntactic matcher, then falls through to structural relation when the two types are not pointer-equal. That shared structural relation asserts that alias rigidness matches. Here the alias shape was the same, but one side had next-solver rigidness state and the other did not.

So imo the better fix is to make MatchAgainstHigherRankedOutlives handle aliases itself. It relates the alias kind and args, but ignores only the IsRigid bit. idk if we want to push this further, but this boundary feels right to me: liveness stays dumb and syntactic, and we do not pre-fold clauses just to satisfy the matcher.

btw I kept the liveness-side identity alias as IsRigid::No and removed the set_aliases_to_rigid calls.

adwinwhite · 2026-07-31T04:23:24Z

We previously have a set_aliases_to_non_rigid hack in extract_verify_if_eq. I removed it and added the asserts in 7c1c571 without noticing this new outlives_for_liveness module.

jackh726 · 2026-07-31T13:55:37Z

@adwinwhite can you review here? You're much more familiar with what might be the correct fix here than I am.

adwinwhite · 2026-07-31T17:06:24Z

r? me
I'll look at it in the next few days.

jackh726 · 2026-07-31T17:52:28Z

Thanks! Ping me if there's a question here for me or something otherwise needed from me!

adwinwhite · 2026-08-04T02:58:41Z

I think we shouldn't weaken the checks in extract_verify_if_eq unless we have no other choice. We want aliases to be rigid in region handling in general. And they probably are.

The reasons we have non-rigid aliases here are

inside live_args_for_alias_from_outlives_bounds, we operates on generic aliases.
item_bounds returns non-rigid predicates.

It's difficult to normalize here. So we have to live with a hack, hopefully less bad :/
Assuming the aliases we visit in FreeRegionVisitor are rigid (should assert this), we can treat the input and instantiated output of live_args_for_alias_from_outlives_bounds as rigid. So we can have Ty::new_alias(.., yes_if_next_solver) in it. The method being a query now is for caching reason, I guess?
As for type-outlives predicates from item_bounds, we only care about those whose self ty is of the same kind as our alias. We can do some filtering similar to the beginning of live_args_for_outlives_clause.

jackh726 · 2026-08-05T19:27:31Z

I would very much not like to land a hack here; I'd like to stay principled in this space, because the soundness around opaque type liveness involves accurately identifying regions that could be within an alias.

This is a query because:

Staying principled: it's much easier to reason about what most hold for all alias instantiation than for any given one
Performance/caching: we don't want to have to, recalculate this for every alias use
Cross-crate metadata: this maybe isn't needed, since everything should be able to be calculated from the definition, which is available across crates

The only thing that I worry about is something like <X as Trait>::Assoc: 'a with an impl impl<T> Trait for T { type Assoc = Struct; }. I think although we could normalize that to Struct: 'a, and then see that trivially holds (because Struct contains no lifetimes), I am concerned about the non-local reasoning required for that.

Dnreikronos · 2026-08-06T12:25:35Z

Wassup, ty both for your time invested!

Two things I hit while working through @adwinwhite's plan that I want to confirm first, because I don't think it and @jackh726's "no hack" constraint fully agree yet.

The filtering I'll just do. The clause that ICEs comes from impl Foo<'x, Out: 'static>, which the AssocItemConstraintKind::Bound arm lowers to <Opaque<'x0> as Foo<'x0>>::Out: 'static. Its self ty is a different alias than the one we're computing for, so filtering on clause_alias.kind == kind drops it before it reaches extract_verify_if_eq, and we lose nothing: the relate would have failed on the def ids anyway.

Question 1: making alias_ty rigid isn't enough by itself. Item bounds are lowered non-rigid unconditionally, both in associated_type_bounds and in opaque_type_bounds. Today alias_ty is non-rigid too, so for a plain fn f<'a>() -> impl Sized + 'a the outlives.0 == alias_ty fast path hits and we never call the matcher. If I flip only alias_ty to yes_if_next_solver, that equality fails, we fall into extract_verify_if_eq, and the assert fires on a case that works today. So the filtered clause's self ty has to be rigidified as well. After the def-id filter that's provably just the top-level bit, since item-bound self types are always the alias at its identity args, so there are no nested aliases and I can assert that. Is that acceptable, or is it the hack you don't want?

Question 2: the assert in FreeRegionsVisitor and the instantiated output pull against each other. EarlyBinder::bind sets everything non-rigid, so the instantiate in the visitor hands non-rigid aliases back in and trips the new assert. Patching that with set_aliases_to_rigid would add the first caller of a function that currently has none, right next to the param-env one that's already commented as a hack.

The alternative I'd rather write: everything the query and args_known_to_outlive_alias_params return is an element of GenericArgs::identity_for_item, so both can return arg indices instead of EarlyBinder<GenericArg>, and the visitor does args[idx].visit_with(self). That drops the binder and the instantiate entirely, so nothing needs a rigidness fold, and the args are rigid because the alias we're visiting is. It also handles the BitSet FIXME. The cost is a changed query signature and rmeta table, and for RPITITs it makes the "opaque params line up positionally with the assoc type params" assumption explicit instead of leaving it implicit in instantiate.

imo the index version is worth the churn even though it's the bigger diff. Every time we launder rigidness through an EarlyBinder we're writing down something we don't actually know, and this module is only going to grow. I'd rather pay for it now than add a second set_aliases_to_rigid caller that someone has to reason about in six months. It does touch the query signature though, so @jackh726 is that the shape you have in mind? lmk if it's more than you want in this PR and I'll do the narrow version instead.

One more, @jackh726, on <X as Trait>::Assoc: 'a with impl<T> Trait for T { type Assoc = Struct; }. That clause reaches liveness through live_args_for_outlives_clause, which is the param-env path rather than the item_bounds path that ICEs. My read is that the rigid assert rules it out, because an alias that normalizes to Struct wouldn't still be rigid by the time borrowck sees it, so we'd never take the restricting branch. Does that match how you're thinking about it, or is there a case where a normalizable alias shows up rigid there?

lcnr · 2026-08-10T07:31:35Z

see discussion on zulip https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841

rustbot · 2026-08-11T12:51:00Z

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Dnreikronos · 2026-08-11T12:53:36Z

@lcnr update: I pulled the bitset work out into #160936 so this PR stays focused on the behavioral / extract_verify_if_eq side.

Zulip context still applies: https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841

imo the bitset was the right first step, but mixing it here made the review surface noisier than it needed to be. the open question on this PR is still the matcher: do we need proper matching/normalization in extract_verify_if_eq, or is underapproximating fine for liveness (only exact Self: 'a / structural eq)? idk which way we want yet.

fyi I left the ignore-rigidness matcher commit here for now. lmk if you'd rather I drop it / swap to the exact-Self: 'a filter asap.

lcnr · 2026-08-11T13:09:42Z

can you split out the bitset change from the behaviorial changes in this PR? ideally open a separate PR for just the bitset change

Dnreikronos · 2026-08-11T13:13:08Z

can you split out the bitset change from the behaviorial changes in this PR? ideally open a separate PR for just the bitset change

Ofc!
I will do it asap

Dnreikronos · 2026-08-11T18:22:29Z

@lcnr split's done.

Bitset landed in #160936. This PR is back to just the behavioral / extract_verify_if_eq stuff.

imo that's cleaner for review. the bitset is pure churn on query shape, and mixing it with the ICE fix was making the diff harder to reason about than it needed to be. lmk if you'd rather I stack #160212 on top of that one instead of keeping them independent.

…t, r=lcnr,jackh726,adwinwhite traits: Represent live alias arguments as bitsets Split out of rust-lang#160212 per review / Zulip: https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841 `live_args_for_alias_from_outlives_bounds` and `args_known_to_outlive_alias_params` now return identity arg indices (`DenseBitSet`) instead of `EarlyBinder<GenericArg>`. Callers just do `args[idx].visit_with(...)`, so we stop laundering rigidness through binder instantiate. Also drops the old BitSet FIXME. imo this is worth doing on its own even without the ICE fix. every time we shoved identity params through `EarlyBinder` we were writing down something we don't actually know, and this module is only going to grow. better to make the invariant explicit now than keep paying for it later. No behavioral change intended. the rigid-alias ICE / `extract_verify_if_eq` bits stay on rust-lang#160212. btw if that one should stack on this instead of staying independent, lmk and I'll rebase it asap.

Rollup merge of #160936 - Dnreikronos:traits/live_args_bitset, r=lcnr,jackh726,adwinwhite traits: Represent live alias arguments as bitsets Split out of #160212 per review / Zulip: https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841 `live_args_for_alias_from_outlives_bounds` and `args_known_to_outlive_alias_params` now return identity arg indices (`DenseBitSet`) instead of `EarlyBinder<GenericArg>`. Callers just do `args[idx].visit_with(...)`, so we stop laundering rigidness through binder instantiate. Also drops the old BitSet FIXME. imo this is worth doing on its own even without the ICE fix. every time we shoved identity params through `EarlyBinder` we were writing down something we don't actually know, and this module is only going to grow. better to make the invariant explicit now than keep paying for it later. No behavioral change intended. the rigid-alias ICE / `extract_verify_if_eq` bits stay on #160212. btw if that one should stack on this instead of staying independent, lmk and I'll rebase it asap.

…,jackh726,adwinwhite traits: Represent live alias arguments as bitsets Split out of rust-lang/rust#160212 per review / Zulip: https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841 `live_args_for_alias_from_outlives_bounds` and `args_known_to_outlive_alias_params` now return identity arg indices (`DenseBitSet`) instead of `EarlyBinder<GenericArg>`. Callers just do `args[idx].visit_with(...)`, so we stop laundering rigidness through binder instantiate. Also drops the old BitSet FIXME. imo this is worth doing on its own even without the ICE fix. every time we shoved identity params through `EarlyBinder` we were writing down something we don't actually know, and this module is only going to grow. better to make the invariant explicit now than keep paying for it later. No behavioral change intended. the rigid-alias ICE / `extract_verify_if_eq` bits stay on rust-lang/rust#160212. btw if that one should stack on this instead of staying independent, lmk and I'll rebase it asap.

rustbot · 2026-09-15T18:50:44Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

adwinwhite

thanks, good stuff :>
Could you squash commits after addressing nits?

View changes since this review

adwinwhite · 2026-09-16T02:19:57Z

@rustbot author

rustbot · 2026-09-16T02:20:02Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Item bounds already instantiate higher-ranked GAT arguments with identity parameters. Compare the bound self type with the identity alias directly, and treat any remaining bound region as static.

Dnreikronos · 2026-09-16T12:46:46Z

@rustbot ready

adwinwhite · 2026-09-17T01:06:57Z

@bors r+ rollup

rust-bors · 2026-09-17T01:07:00Z

📌 Commit fb554f2 has been approved by adwinwhite

It is now in the queue for this repository.

…eness, r=adwinwhite traits: Fix rigid alias liveness matching Fixes rust-lang#160206 The ICE happens while borrowck computes liveness for an opaque return type with an associated type bound. In the repro, that bound looks like `<impl Foo<'x> as Foo<'x>>::Out: 'static`. The query passes unnormalized item bounds to `extract_verify_if_eq`, which expects rigid aliases with the next solver, and hits its debug assertion. Item-bound collection already maps higher-ranked GAT arguments to the GAT's identity parameters. That means this query can compare the bound's self type directly with the identity alias. A bound on a nested projection, like the associated type in the repro, doesn't match the opaque itself and gets skipped. It doesn't tell us that the opaque is `'static`. For bounds that do match, we keep the outlives region unless it's still bound. For example, `for<'b> Self::Assoc<'b>: 'b` becomes a non higher ranker item bound `Self::Assoc<'param>: 'param`, so that param region still matters for liveness. With `for<'b> Self::Assoc: 'b`, the same associated type has to outlive every choice of `'b`, including `'static`. We handle that case directly. I think this is a better fit for the query because it uses the work item-bound collection already did. It removes the matcher call from this path and keeps the shared matcher's rigidity checks intact. The separate call for function bounds stays, since it still needs to match against the alias's concrete arguments. There's no extra normalization in liveness. The original repro covers the case that triggered the assertion: an item bound on a nested projection must be skipped when computing liveness for the opaque itself.

Rollup of 12 pull requests Successful merges: - #161596 (coretests: Add more pattern tests.) - #162796 (libtest: do not early exit from test runners) - #162844 (Add loan reachability traces to polonius MIR dumps) - #158186 (Guarantee 8 bytes of alignment of RawWakerVTable) - #160108 (Stabilize `windows_process_extensions_main_thread_handle`) - #160212 (traits: Fix rigid alias liveness matching) - #160544 (Stabilize `feature(trim_prefix_suffix)` (`{str, [T], Path}::trim_prefix` and `{str, [T]}::trim_suffix`)) - #161305 (Use the entire type of a dropped local to compute variance (edge direction) for Polonius alpha) - #161838 (tests: accept LLVM 24 optimization in this test) - #162805 (Add `must_use` lint to `ExitCode`) - #162825 (core: Add examples for `debug_closure_helpers`) - #162856 (Stabilize CommandExt::show_window)

…eness, r=adwinwhite traits: Fix rigid alias liveness matching Fixes rust-lang#160206 The ICE happens while borrowck computes liveness for an opaque return type with an associated type bound. In the repro, that bound looks like `<impl Foo<'x> as Foo<'x>>::Out: 'static`. The query passes unnormalized item bounds to `extract_verify_if_eq`, which expects rigid aliases with the next solver, and hits its debug assertion. Item-bound collection already maps higher-ranked GAT arguments to the GAT's identity parameters. That means this query can compare the bound's self type directly with the identity alias. A bound on a nested projection, like the associated type in the repro, doesn't match the opaque itself and gets skipped. It doesn't tell us that the opaque is `'static`. For bounds that do match, we keep the outlives region unless it's still bound. For example, `for<'b> Self::Assoc<'b>: 'b` becomes a non higher ranker item bound `Self::Assoc<'param>: 'param`, so that param region still matters for liveness. With `for<'b> Self::Assoc: 'b`, the same associated type has to outlive every choice of `'b`, including `'static`. We handle that case directly. I think this is a better fit for the query because it uses the work item-bound collection already did. It removes the matcher call from this path and keeps the shared matcher's rigidity checks intact. The separate call for function bounds stays, since it still needs to match against the alias's concrete arguments. There's no extra normalization in liveness. The original repro covers the case that triggered the assertion: an item bound on a nested projection must be skipped when computing liveness for the opaque itself.

rustbot assigned JohnTitor Jul 30, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Jul 30, 2026

This comment has been minimized.

Sign in to view

jackh726 reviewed Jul 30, 2026

View reviewed changes

rustbot assigned adwinwhite and unassigned JohnTitor Jul 31, 2026

This comment has been minimized.

Sign in to view

Dnreikronos force-pushed the traits/rigid_alias_liveness branch from a9ef45e to 5c1eddb Compare August 6, 2026 12:28

This comment has been minimized.

Sign in to view

Dnreikronos mentioned this pull request Aug 11, 2026

traits: Represent live alias arguments as bitsets #160936

Merged

Dnreikronos force-pushed the traits/rigid_alias_liveness branch from 3d4d472 to db4cb2b Compare August 11, 2026 18:22

This comment has been minimized.

Sign in to view

Dnreikronos force-pushed the traits/rigid_alias_liveness branch from db4cb2b to 97b5b5a Compare September 15, 2026 18:50

adwinwhite reviewed Sep 16, 2026

View reviewed changes

Comment thread compiler/rustc_trait_selection/src/traits/outlives_for_liveness.rs Outdated

Comment thread tests/ui/borrowck/alias-liveness/higher-ranked-item-bounds-capture.current.stderr Outdated

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 16, 2026

Read alias liveness directly from item bounds

fb554f2

Item bounds already instantiate higher-ranked GAT arguments with identity parameters. Compare the bound self type with the identity alias directly, and treat any remaining bound region as static.

Dnreikronos force-pushed the traits/rigid_alias_liveness branch from 97b5b5a to fb554f2 Compare September 16, 2026 12:38

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 16, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 17, 2026

Zalathar mentioned this pull request Sep 17, 2026

Rollup of 12 pull requests #162877

Closed

Zalathar mentioned this pull request Sep 17, 2026

Rollup of 11 pull requests #162878

Open

Uh oh!

Uh oh!

Conversation

Dnreikronos commented Jul 30, 2026 • edited by adwinwhite Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 30, 2026

Uh oh!

This comment has been minimized.

jackh726 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Dnreikronos commented Jul 30, 2026

Uh oh!

adwinwhite commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jackh726 commented Jul 31, 2026

Uh oh!

adwinwhite commented Jul 31, 2026

Uh oh!

jackh726 commented Jul 31, 2026

Uh oh!

adwinwhite commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

jackh726 commented Aug 5, 2026

Uh oh!

Dnreikronos commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

lcnr commented Aug 10, 2026

Uh oh!

rustbot commented Aug 11, 2026

Uh oh!

Dnreikronos commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

lcnr commented Aug 11, 2026

Uh oh!

Dnreikronos commented Aug 11, 2026

Uh oh!

This comment has been minimized.

Dnreikronos commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 15, 2026

Uh oh!

adwinwhite left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

adwinwhite commented Sep 16, 2026

Uh oh!

rustbot commented Sep 16, 2026

Uh oh!

Dnreikronos commented Sep 16, 2026

Uh oh!

adwinwhite commented Sep 17, 2026

Uh oh!

rust-bors Bot commented Sep 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Dnreikronos commented Jul 30, 2026 •

edited by adwinwhite

Loading

jackh726 left a comment •

edited by rustbot

Loading

adwinwhite commented Jul 31, 2026 •

edited

Loading

adwinwhite commented Aug 4, 2026 •

edited

Loading

Dnreikronos commented Aug 6, 2026 •

edited

Loading

Dnreikronos commented Aug 11, 2026 •

edited

Loading

Dnreikronos commented Aug 11, 2026 •

edited

Loading

adwinwhite left a comment •

edited by rustbot

Loading