abby: always store nextgen region constraints in canonical form

[BoxyUwU]

View all comments

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]

r? @lcnr @khyperia

[rustbot]

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]

@bors r+ rollup=never

[rust-bors]

📌 Commit b22bffa has been approved by BoxyUwU

It is now in the queue for this repository.

[BoxyUwU]

@bors r=lcnr,khyperia

[rust-bors]

📌 Commit b22bffa has been approved by lcnr,khyperia

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: lcnr,khyperia
Duration: 3h 10m 8s
Pushing d8df826 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 4fcf397 (parent) -> d8df826 (this PR)

Test differences

Show 16 test diffs

Stage 0

• infer::solver_region_constraints::tests::canonicalization_preserves_only_one_ambiguity: [missing] -> pass (J1)
• infer::solver_region_constraints::tests::evaluation_is_span_agnostic: pass -> [missing] (J1)
• infer::solver_region_constraints::tests::evaluation_preserves_first_ambiguity_span: pass -> [missing] (J1)

Stage 1

• infer::solver_region_constraints::tests::canonicalization_preserves_only_one_ambiguity: [missing] -> pass (J0)
• infer::solver_region_constraints::tests::evaluation_is_span_agnostic: pass -> [missing] (J0)
• infer::solver_region_constraints::tests::evaluation_preserves_first_ambiguity_span: pass -> [missing] (J0)

Additionally, 10 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple-2, aarch64-apple-macos-26-2, aarch64-gnu, aarch64-gnu-llvm-21-2, aarch64-msvc-2, i686-gnu-2, i686-gnu-nopt-2, i686-msvc-2, x86_64-gnu, x86_64-gnu-llvm-21-1, x86_64-gnu-llvm-22-1, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-2, x86_64-msvc-2
• J1: x86_64-gnu-llvm-21-3, x86_64-gnu-llvm-22-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard d8df82673d5911b6112a85bf91d9adefb2c66a1a --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-msvc-ext1: 1h 35m -> 2h 19m (+46.5%)
2. i686-gnu-nopt-2: 1h 39m -> 2h 23m (+44.6%)
3. dist-riscv64-linux-gnu: 1h 5m -> 1h 29m (+38.2%)
4. x86_64-mingw-1: 2h 14m -> 2h 59m (+34.0%)
5. dist-x86_64-msvc-alt: 2h 8m -> 2h 51m (+33.7%)
6. x86_64-gnu-miri: 1h 7m -> 1h 30m (+33.1%)
7. x86_64-gnu-nopt: 2h 28m -> 1h 40m (-32.3%)
8. i686-gnu-nopt-1: 2h 17m -> 1h 36m (-29.8%)
9. x86_64-gnu-llvm-21-3: 1h 53m -> 1h 20m (-29.2%)
10. dist-x86_64-mingw: 2h 5m -> 2h 41m (+28.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (d8df826): comparison URL.

Overall result: ❌ regressions - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.5%]	57
Regressions ❌ (secondary)	0.3%	[0.1%, 0.6%]	41
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	0.2%	[0.1%, 0.5%]	57

Max RSS (memory usage)

Results (primary -1.7%, secondary -1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-4.0%	[-7.0%, -0.9%]	2
All ❌✅ (primary)	-1.7%	[-1.7%, -1.7%]	1

Cycles

Results (secondary 6.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.8%	[6.8%, 6.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	15
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	5
All ❌✅ (primary)	-0.0%	[-0.1%, -0.0%]	15

Bootstrap: 476.065s -> 477.112s (0.22%)
Artifact size: 401.18 MiB -> 401.86 MiB (0.17%)