Region inference: Use outlives-static constraints in constraint search

[amandasystems]

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]

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

[amandasystems]

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

[lcnr]

@bors try @rust-timer queue

[bors]

⌛ Trying commit a209255 with merge 0d3d480...

[bors]

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

[rust-timer]

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%)

[lcnr]

why can we not use the region from max_nameable_universe here?

[amandasystems]

That sometimes slightly worsens the error messages (or at least causes diagnostics regressions) because previous logic picked the first smallest region. It's very annoying.

[lcnr]

can you dump the changes caused by this somewhere? I personally believe that some amount of diagnostics regression is acceptable if it cleans up the code/removes subtly different variations of the same concept.

[amandasystems]

Here's the an output from the UI tests attached when doing that!

$ ./x test ui --keep-stage 1 > simpler-choice-blame-ui-tests.log

simpler-choice-blame-ui-tests.log

There's a bunch of squiggly lines getting longer, which I think is mostly harmless:

• tests/ui/higher-ranked/higher-ranked-lifetime-error.rs: I'd say fully harmless, a slightly longer squiggly line
• tests/ui/higher-ranked/trait-bounds/due-to-where-clause.rs same as above
• tests/ui/mismatched_types/hr-projection-mismatch.rs#current same as above

Then there is a duplicate of a diagnostic due to a longer span which we may or may not care about, in tests/ui/associated-inherent-types/issue-111404-1.rs. This should be very fixable in the error reporting phase, but that part of the code is absolutely incomprehensible (though I've tried), and I've simply given up on it.

I remember this being much, much worse! Maybe this is acceptable?

[amandasystems]

If you think this is ok, say the word and I'll dump like half the file to get rid of this extra logic!

[lcnr]

This is okay to me and I would prefer getting rid of this extra logic. Though I could imagine us improving these diagnostics with at least one hacky way. Instead of using the first max_universe, we could do fun stuff with it. If we're able to pass in the regionctxt/region info into merge_sccs we can decide the best region based on its origin/span.

What happens if pick_min_max_universe just uses the region with the lowest VID if universes are equal?

[amandasystems]

What happens if pick_min_max_universe just uses the region with the lowest VID if universes are equal?

The code is even simpler and more deterministic, since it's just a regular std::cmp::min and now doesn't depend on the ordering of visits in the region graph during SCC construction. It was in fact the first logic I wrote for that reason, and because someone (Niko?) suggested that we generally like lower vids, but I left it to try to avoid the more complicated logic you suggested I remove, before realising it was unavoidable.

Following the spirit of the suggestion, rather than just doing precisely that, the code for merging SCC annotations also becomes a oneliner, rather than a complicated if statement that nopes out early once we find a universe violation, so this is a large (but less huge) win. Originally, I stopped merging at the first sign of trouble, but since we want to keep looking for smaller rvids, it now has to run until every last merge is done.

If I do that, the UI tests outcome (compared to the one above) is as above, plus:

• (this is the reason I started doing this complicated logic because this note is NO FUN to figure out why it gets added): tests/ui/generic-associated-types/bugs/hrtb-implied-2.rs : missing note about due to limitations of borrow checker, implied static
• tests/ui/nll/local-outlives-static-via-hrtb.rs: shorter squiggly line (picks the AssociatedType as opposed to the Reference on L38)
• One fewer reported error (no "E0308 one type is more general than another") on l. 14 in tests/ui/nll/relate_tys/placeholder-outlives-existential.rs (one error is still being reported). My assumption here is that there are multiple error paths within/from the same SCC and we now pick a less complicated one that doesn’t trigger that error. I’m not super worried since this error is detected separately in my next PR.

If I don't stop merging early on first error, I get the literal same output as above, everywhere.

If we're able to pass in the regionctxt/region info into merge_sccs we can decide the best region based on its origin/span

Sounds doable.

[rustbot]

⚠️ Warning ⚠️

• This PR is based on an upstream commit that is 28 days old.

  It's recommended to update your branch according to the rustc-dev-guide.