abby: always store nextgen region constraints in canonical form

[BoxyUwU]

title. introduce an And/Or/LeafConstraint/CanonicalFormRegionConstraint 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 CanonicalFormRegionConstraint is:

• CanonicalFormRegionConstraint 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 CanonicalFormRegionConstraint::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 CanonicalFormRegionConstraint. 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 70a8c63 which actually replaces RegionConstraint with all the new types and updates all the locations using them.

Finally there's 1bead00 which deals with the leftover evaluate_solver_constraint which was mostly unnecessary now due to moving its main logic into construction of CanonicalFormRegionConstraint 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

This will merge conflict with both #161443 and #158588. I don't expect this PR to get approved before those but if it does I intend to wait for those PRs to land first then merge this.

[BoxyUwU]

r? @lcnr @khyperia

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

checking C++ file formatting
spellchecking files
building external tool typos from package typos-cli@1.38.1
finished building tool typos
error: `unncessarily` should be `unnecessarily`
    ╭▸ compiler/rustc_type_ir/src/region_constraint.rs:479:78
    │
479 │         // as we might end up with `'a: 'b` being satisfied in which case we unncessarily
    ╰╴                                                                             ━━━━━━━━━━━━
rerun with `--bless` to fix typos: `./x.py test tidy --extra-checks=spellcheck --bless`
tidy [extra_checks:spellcheck]: checks with external tool 'typos' failed
tidy [extra_checks:spellcheck]: FAIL
yarn install v1.22.22
warning package.json: No license field
warning ../../package.json: License should be a valid SPDX license expression
warning No license field
[1/4] Resolving packages...
---
Running eslint on rustdoc JS files
info: ES-Check: checking 7 files...
info: ✓ ES-Check passed! All files are ES10 compatible.
typechecking javascript files
tidy: The following check failed: extra_checks:spellcheck
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Currently active steps:
test::Tidy {  } at src/bootstrap/src/core/build_steps/test.rs:1661
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/checkout --cargo-path=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/checkout/obj/build --concurrency=4 --npm-path=/node/bin/yarn --ci=true --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1743:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:02:43
  local time: Fri Aug 21 16:35:10 UTC 2026
  network time: Fri, 21 Aug 2026 16:35:10 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[rust-bors]

☔ The latest upstream changes (presumably #161505) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[khyperia]

looks good to me, I just have lots of vague little unimportant nits that you're free to ignore!

again, lmk if you'd like me to help rebase this on the testing DSL work, I'm happy to adapt the DSL to this format.

View changes since this review

[khyperia]

nit: IMO either have this whole thing be iterator-based, or have none of it be, not in between

let mut ands = Vec::new();
for b_and in b.0 {
    for a_and in &a.0 {
        ands.push(And::new(a_and.0.clone().into_iter().chain(b_and.0.clone())));
    }
}

or

let ands = b.0.into_iter().flat_map(|b_and| {
    a.0.clone()
        .into_iter()
        .map(move |a_and| And::new(a_and.0.into_iter().chain(b_and.0.clone())))
});

[khyperia]

nit: .collect() works into Box<[_]>, so this can just be .collect() without .into_boxed_slice().

(unless there's some perf reason to do double? idk what exactly the collect impl for a boxed slice is, if it has excess elements at the end or whatever).

there's a few other places that could be more clever about iterators and collects and whatnot, e.g. Or::new, that would remove excess allocations, but tbh this is all wip perf hell anyway and probably doesn't matter at the moment

[khyperia]

nit: this struct is referred to in a bunch of places, and I personally kinda dislike having the implementation detail of the wording of "canonical form" splatted over the rest of the codebase where it kinda doesn't care that this is a bag of ands and an or of ands.

thinking of alternatives, hmm, RegionConstraints is kind of a bad name since it's just a single letter difference, but idk, some kind of bikeshed. But shrug, doesn't particularly matter, name is fine as-is too.