Region inference: Use outlives-static constraints in constraint search #140737

amandasystems · 2025-05-07T11:12:09Z

Revise the extra r: 'static constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive 'static.

This cosmetically changes the output of two UI tests. I blessed them i separate commits with separate motivations, but that can of course be squashed as desired. We probably want that.

The PR was extracted out of #130227 and consists of one-third of its functional payload.

r? lcnr

bors · 2025-06-05T09:38:19Z

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

amandasystems · 2025-06-09T11:48:37Z

(We may also want a perf run to see if I messed something up badly)

lcnr · 2025-06-09T11:49:59Z

@bors try @rust-timer queue

Region inference: Use outlives-static constraints in constraint search Revise the extra `r: 'static` constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive `'static`. This cosmetically changes the output of two UI tests. I blessed them i separate commits with separate motivations, but that can of course be squashed as desired. We probably want that. The PR was extracted out of #130227 and consists of one-third of its functional payload. It is based on #140466, so that has to land first. We probably want a perf run of this. It shouldn't have much of an impact and a positive one if any, but I have been wrong before. In particular, SCC annotations are heavier now. r? lcnr

bors · 2025-06-09T11:51:10Z

⌛ Trying commit a209255 with merge 0d3d480...

bors · 2025-06-09T14:19:00Z

☀️ Try build successful - checks-actions
Build commit: 0d3d480 (0d3d48082efe47a20c953415945cc721105e5f85)

rust-timer · 2025-06-09T15:46:52Z

Finished benchmarking commit (0d3d480): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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.3%]	12
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-0.6%, -0.5%]	6
All ❌✅ (primary)	0.2%	[0.1%, 0.3%]	12

Max RSS (memory usage)

Results (primary 0.4%, secondary -1.0%)

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

	mean	range	count
Regressions ❌ (primary)	1.4%	[1.3%, 1.5%]	2
Regressions ❌ (secondary)	3.0%	[3.0%, 3.0%]	1
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-1.9%	[-2.4%, -0.6%]	4
All ❌✅ (primary)	0.4%	[-1.7%, 1.5%]	3

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 753.257s -> 756.017s (0.37%)
Artifact size: 372.34 MiB -> 372.33 MiB (-0.00%)

…=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang#140737 (comment). r? types cc `@amandasystems`

…=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang#140737 (comment). r? types cc ``@amandasystems``

…=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang#140737 (comment). r? types cc ```@amandasystems```

…=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang#140737 (comment). r? types cc `@amandasystems`

…=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang#140737 (comment). r? types cc ``@amandasystems``

…=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang#140737 (comment). r? types cc ```@amandasystems```

Rollup merge of #145041 - lcnr:borrowck-limitations-error, r=BoxyUwU rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in #140737 (comment). r? types cc ```@amandasystems```

amandasystems · 2025-08-19T10:41:49Z

@rustbot ready

amandasystems · 2025-08-19T10:43:08Z

We may also want a new perf run since I have changed the code that runs during SCC construction which might affect performance (positively, I hope)

lcnr · 2025-08-19T11:59:19Z

@bors try @rust-timer queue

Region inference: Use outlives-static constraints in constraint search

compiler/rustc_borrowck/src/region_infer/mod.rs

rust-bors · 2025-08-19T14:16:49Z

☀️ Try build successful (CI)
Build commit: 834fbf1 (834fbf1e2aa01b56f03cb70cc1f290e146189916, parent: 8365fcb2b840c95eeb0bc377af8bd498fad22245)

rust-timer · 2025-08-19T15:26:17Z

Finished benchmarking commit (834fbf1): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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)	4.7%	[4.7%, 4.7%]	1
Regressions ❌ (secondary)	0.4%	[0.2%, 0.6%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.6%, -0.2%]	14
All ❌✅ (primary)	4.7%	[4.7%, 4.7%]	1

Max RSS (memory usage)

Results (primary 1.7%, secondary -2.8%)

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

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-5.0%, -1.9%]	4
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

Cycles

Results (primary 3.8%, secondary 43.8%)

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

	mean	range	count
Regressions ❌ (primary)	3.8%	[3.8%, 3.8%]	1
Regressions ❌ (secondary)	43.8%	[39.1%, 49.9%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.8%	[3.8%, 3.8%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 471.447s -> 469.972s (-0.31%)
Artifact size: 378.21 MiB -> 378.17 MiB (-0.01%)

bors · 2025-08-21T07:39:33Z

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

lcnr · 2025-08-21T08:19:53Z

compiler/rustc_borrowck/src/handle_placeholders.rs

+
+        added_constraints = true;
+        outlives_constraints.push(OutlivesConstraint {
+            sup: annotation.representative.rvid(),


As for the other case, this would happen when we have an SCC representative r for SCC S whose computed universe was lowered. I think this always happens because it shares SCC with an existential e with a lower universe. In that case r would be the unnameable region, which in some cases triggers a search for a path from r to r, which ICEs, so I blame e instead.

Hmm... ah 🤔 I think up until now I didn't really appreciate the difference between having constraints between SCCs (necessary for correctness) and between region values (necessary for useful diagnostics)

So using the representative as sup can hide why the placeholder is unnameable placeholder.

Where are we already using the the region vid of the max_nameable_universe? I feel like we sohuld use that region vid as the sup here

I think that interferes with the tracing code/search redirect I currently have but you’re right that would make more sense. I’ll see if it’s easily tweakable.

In this case, the max_nameable_universe's rvid is in the explanation on the edge I add. I always add outgoing edges from the representative, basically on priniciple. So perhaps the name is wrong, and the meaning of the annotation is more "this is the region you want to blame for this edge existing", as opposed to "this is an unnameable placeholder".

If I use small_universed_rvid as sup and always put in the actual unnameable placeholder as the edge annotation I instead have to catch the complexity of the situation at the other end, or I get "no path in graph" ICEs, because the search is now going essentially in the wrong direction on:

tests/ui/impl-trait/nested-rpit-hrtb.rs tests/ui/associated-inherent-types/issue-111404-1.rs tests/ui/associated-consts/assoc-const-eq-bound-var-in-ty-not-wf.rs

The complexity of this situation has to be handled somewhere, and it's slightly easier to handle it when creating the constraint compared to when catching it during blame search, and have the constraint meaning just be "look for this region!".

(I suspect this is also mitigated when placeholder-placeholder and placeholder-existential errors are handled separately later and the logic of this part only does one thing, but I worry there might be residual bits of the error explanation code that assumes that something like this structure exists because it was how the do-the-logic-during-propagation code used to work)

okay, so i had a thought that this is still incorrect, in a sense this constraint does exist for all members of the scc but we should then figure out to path from each of them to the placeholder 🤔

that's hard to model, so I think the status quo is fine.

If I use small_universed_rvid as sup and always put in the actual unnameable placeholder as the edge annotation I instead have to catch the complexity of the situation at the other end, or I get "no path in graph" ICEs, because the search is now going essentially in the wrong direction on:

Oh.. the issue is something like this: 'a[1]: 'b[0], 'a[1]: 'placeholder[1]. As in
'a can name 'placeholder, but can't because we lower it's universe to be nameable by 'b?

That's scuffed. we could totally infer 'a to 'placeholder and only constrain 'b to 'static... i haven't thought of this before, but I feel like that's just broken in a weird way and I am unsure whether it's observable without where-bounds on binders

okay, i think this isn't currently an issue as 'placeholder: existential_it_cant_name always errors, but it will be a problem in the future 💀

Yeah, that whole logic is cursed. I'd love to clean it up more, but uh, I'd also like to land my PRs at some point.

lcnr · 2025-08-22T10:17:42Z

compiler/rustc_borrowck/src/region_infer/mod.rs

@@ -2025,7 +1970,7 @@ impl<'tcx> RegionInferenceContext<'tcx> {
                // specific, and are not used for relations that would make sense to blame.
                ConstraintCategory::BoringNoLocation => 6,
                // Do not blame internal constraints.
-                ConstraintCategory::IllegalUniverse => 7,
+                ConstraintCategory::OutlivesUnnameablePlaceholder(_) => 7,


change this to unreachable? 😁

It is reachable in case we take the else branch (if we're starting in the unnameable region).

lcnr · 2025-08-22T10:20:55Z

needs rebase :>

Revise the extra `r: 'static` constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive 'static.

rustbot · 2025-08-22T11:38:54Z

This PR was rebased onto a different master 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.

rustbot assigned lcnr May 7, 2025

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. labels May 7, 2025

amandasystems force-pushed the revised-constraint-search branch from f4af776 to 72e81ea Compare May 16, 2025 10:14

amandasystems mentioned this pull request May 26, 2025

Move placeholder handling to a proper preprocessing step #140466

Merged

amandasystems force-pushed the revised-constraint-search branch from 72e81ea to 9a1face Compare May 27, 2025 10:09