Canonicalize free regions from inputs as placeholders in root univ

[ShoyuVanilla]

Context: The box named coroutine witness Send lifetime requirements now considered by leakcheck this roadmap

Fixes (only for the next-solver) #106569
Prerequisite of #155749

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: e39d9d1 (e39d9d1e2232da07330c87d8314c3587ec4edb1f, parent: 8da2d28cbd5a4e2b93e028e709afe09541671663)

[rust-timer]

Finished benchmarking commit (e39d9d1): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@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
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	4
Improvements ✅ (primary)	-1.1%	[-4.4%, -0.2%]	40
Improvements ✅ (secondary)	-1.1%	[-3.2%, -0.1%]	33
All ❌✅ (primary)	-1.1%	[-4.4%, -0.2%]	40

Max RSS (memory usage)

Results (primary 2.8%, secondary 3.2%)

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

	mean	range	count
Regressions ❌ (primary)	2.8%	[1.0%, 5.5%]	7
Regressions ❌ (secondary)	3.2%	[1.6%, 4.8%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.8%	[1.0%, 5.5%]	7

Cycles

Results (primary -3.2%, secondary 0.2%)

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.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-3.2%	[-4.0%, -2.3%]	7
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	-3.2%	[-4.0%, -2.3%]	7

Binary size

Results (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
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	4
All ❌✅ (primary)	-	-	0

Bootstrap: 493.313s -> 494.404s (0.22%)
Artifact size: 394.36 MiB -> 394.31 MiB (-0.01%)

[ShoyuVanilla]

r? lcnr

[ShoyuVanilla]

We have lots of those ...but it actually implements X for some specific lifetime '?x -> ...but it actually implements X for some specific lifetime diagnostic drifts due to the canonicalized region being placeholders rather than region vars.
I think this is somewhat regressive. Would it make sense to fix them somehow?

View changes since the review

[ShoyuVanilla]

I'm not sure I should do something with diagnostics but marking this as ready 😅

[lcnr]

shouldn't just placeholder.universe() != ty::UniverseIndex::ROOT be enough here. We should never add new placeholders to an existing universe and max_input_universe is guaranteed to be able to the root universe, as can_name is equivalent to max_input_universe >= placeholder.universe()

View changes since the review

[ShoyuVanilla]

Wouldn't there still be the cases that adding new placeholders to a new_universe > max_input_universe?

[lcnr]

ah, yeah, it's the other way around

• either the placeholder is in the root universe
• or from a universe which can't be named by max_input_universe

[lcnr]

2 thoughts here:

It's somewhat scary that this requires literally no changes when we instantiate query responses. I guess what's happening is that this is (another) load bearing use of query_response_instantiation_guess (old solver) and the hack in compute_query_response_instantiation_values (next solver). We should definitely at least update the comments here.

Related to the above, it feels scary to me to change the old solver canonicalization here. I think your change also makes the different CanonicalizeMode be slightly outdated or what not 🤔 could you just limit this to the new solver for now?

CanonicalizeUserTypeAnnotations is interesting to me as that one is more a canonicalize_response where the var_values are just the early/late bound params in the parent function

View changes since this review

[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.

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: ea40b77 (ea40b771b00a2c3ece545cf16f8da7da1ce8125f, parent: 2f43fe430374fce8c75d477bdb78715d5c0349c4)

[rust-timer]

Finished benchmarking commit (ea40b77): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@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
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-2.9%, -0.8%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -6.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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.9%	[-6.9%, -6.9%]	1
All ❌✅ (primary)	-	-	0

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 487.764s -> 486.922s (-0.17%)
Artifact size: 393.48 MiB -> 393.47 MiB (-0.00%)