abby: always store nextgen region constraints in canonical form by BoxyUwU · Pull Request #161306 · rust-lang/rust

BoxyUwU · 2026-08-18T14:30:27Z

title. introduce an And/Or/LeafConstraint/ types to reason about the structure of our region constraints. Never produce arbitrarily nested or/ands and always have constraints in an evaluated form.

I kinda mucked up this PR and accidentally did two things at the same time. Not only do we immediately put everything into canonical form, we also change what it means for a region constraint to be in canonical form. Whoops :>

Rough overview of what a RegionConstraint is:

RegionConstraint contains two things: an AND of LEAFs and an OR of AND of LEAFs. Another way of thinking about it would be to say its an AND consisting of arbitrarily many LEAFs and a single OR of AND of LEAFs
There are never any region constraints shared between all ANDs of the OR, instead they're moved into the top level AND
If the OR constraint is false then we wipe the top level AND as it doesn't matter what they are, the constraint is always going to be false
ORs never have two equivalent ANDs within them. Similarly, ANDs never have two equivalent LEAFs within them

this simplifies a lot of things conceptually as we now no longer need to worry about what state our region constraints are in. and our algorithms also don't need to handle arbitrary nesting of ors/ands :) and its a lot easier to read the debug logs 😅

I also wound up needing to do this while trying to compile std/core with -Zassumptions-on-binders as we would otherwise OOM from having both:

Lots of duplicate region constraints (e.g. And('a: 'b, 'a: 'b))
Lots of region constraints shared across all elements of an OR (e.g. Or(And('a: 'b, 'b: 'c), And('a: 'b, 'b: 'd)))

Some future work:

Remove RegionConstraint::splatted_and_constraints it's kind of weird to even need it and probably encourages bad-for-perf patterns
we Probably want some kind of fast path for pushing new leaf constraints to the region constraint storage. slash have a way to register a leaf constraint directly rather than having to make a RegionConstraint. Perf stuff :3

In theory this PR should mostly not have functional changes. In practice it might affect some things due to changing the exact repr of things affecting query responses. There's probably also some behaviour differences here due to us falling on our face more or less in WIP parts of abby now that we have different region constraints. I don't think any of this should be meaningful though. This PR is intended to not fundamentally change the abby algorithm :3

This PR should be reviewed commit-by-commit. There are a bunch of commits restructuring existing logic to assume their input is in canonical form as it will be by the end of the PR.

Then there's the core change in always canonical form which actually replaces RegionConstraint with all the new types and updates all the locations using them.

Finally there's propagate ambiguity not evaluate which deals with the leftover evaluate_solver_constraint which was mostly unnecessary now due to moving its main logic into construction of RegionConstraint and friends. I didn't want to make actual bug fixes in this PR so I just left some FIXMEs about some of the issues that propagate_ambiguity has instead of fixing them here.

Fixes rust-lang/project-assumptions-on-binders#14

BoxyUwU · 2026-08-21T16:24:22Z

r? @lcnr @khyperia

lcnr · 2026-09-02T09:37:26Z

    }

-    new_constraints
+    RegionConstraint::new_from_or(


also horrible for perf xd, pls FIXME

View changes since the review

lcnr

nits, then r=me

View changes since this review

rustbot · 2026-09-02T12:38:10Z

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.

BoxyUwU · 2026-09-02T14:53:57Z

@bors r+ rollup=never

rust-bors · 2026-09-02T14:54:00Z

📌 Commit b22bffa has been approved by BoxyUwU

It is now in the queue for this repository.

BoxyUwU · 2026-09-02T14:54:02Z

@bors r=lcnr,khyperia

rust-bors · 2026-09-02T14:54:04Z

📌 Commit b22bffa has been approved by lcnr,khyperia

It is now in the queue for this repository.

rust-bors · 2026-09-03T10:24:21Z

⌛ Testing commit b22bffa with merge d8df826...

Workflow: https://github.com/rust-lang/rust/actions/runs/33744111368

…yperia abby: always store nextgen region constraints in canonical form title. introduce an `And`/`Or`/`LeafConstraint`/ types to reason about the structure of our region constraints. Never produce arbitrarily nested or/ands and always have constraints in an evaluated form. I kinda mucked up this PR and accidentally did two things at the same time. Not only do we immediately put everything into canonical form, we also change what it means for a region constraint to be in canonical form. Whoops :> Rough overview of what a `RegionConstraint` is: - `RegionConstraint` contains two things: an `AND of LEAFs` and an `OR of AND of LEAFs`. Another way of thinking about it would be to say its an `AND` consisting of arbitrarily many LEAFs and a single `OR of AND of LEAFs` - There are never any region constraints shared between all ANDs of the OR, instead they're moved into the top level AND - If the OR constraint is `false` then we wipe the top level `AND` as it doesn't matter what they are, the constraint is always going to be false - ORs never have two equivalent ANDs within them. Similarly, ANDs never have two equivalent LEAFs within them this simplifies a lot of things conceptually as we now no longer need to worry about what state our region constraints are in. and our algorithms also don't need to handle arbitrary nesting of ors/ands :) and its a lot easier to read the debug logs 😅 I also wound up needing to do this while trying to compile `std`/`core` with `-Zassumptions-on-binders` as we would otherwise OOM from having both: - Lots of duplicate region constraints (e.g. `And('a: 'b, 'a: 'b)`) - Lots of region constraints shared across all elements of an `OR` (e.g. `Or(And('a: 'b, 'b: 'c), And('a: 'b, 'b: 'd))`) Some future work: - Remove `RegionConstraint::splatted_and_constraints` it's kind of weird to even need it and probably encourages bad-for-perf patterns - we Probably want some kind of fast path for pushing new leaf constraints to the region constraint storage. slash have a way to register a leaf constraint directly rather than having to make a `RegionConstraint`. Perf stuff :3 In theory this PR should mostly not have functional changes. In practice it might affect some things due to changing the exact repr of things affecting query responses. There's probably also some behaviour differences here due to us falling on our face more or less in WIP parts of abby now that we have different region constraints. I don't think any of this should be meaningful though. This PR is intended to not fundamentally change the abby algorithm :3 This PR should be reviewed commit-by-commit. There are a bunch of commits restructuring existing logic to assume their input is in canonical form as it will be by the end of the PR. Then there's the core change in `always canonical form` which actually replaces `RegionConstraint` with all the new types and updates all the locations using them. Finally there's `propagate ambiguity not evaluate` which deals with the leftover `evaluate_solver_constraint` which was mostly unnecessary now due to moving its main logic into construction of `RegionConstraint` and friends. I didn't want to make actual bug fixes in this PR so I just left some FIXMEs about some of the issues that `propagate_ambiguity` has instead of fixing them here. Fixes rust-lang/project-assumptions-on-binders#14