Do not use global caches if opaque types can be defined

[oli-obk]

fixes #119272

r? @lcnr

This is certainly a crude way to make the cache sound wrt opaque types, but since perf lets us get away with this, let's do it in the old solver and let the new solver fix this correctly once and for all.

cc #122192 (comment)

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 0714168 with merge 22162a8...

[bors]

☀️ Try build successful - checks-actions
Build commit: 22162a8 (22162a8d2d0d3c15a3c43166a998f04a7d83769b)

[rust-timer]

Finished benchmarking commit (22162a8): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.5%, 1.5%]	6
Regressions ❌ (secondary)	6.3%	[0.6%, 14.5%]	14
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.5%, 1.5%]	6

Max RSS (memory usage)

Results (secondary 4.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

Results (primary -0.7%, secondary 3.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	11.7%	[9.5%, 13.5%]	6
Improvements ✅ (primary)	-0.7%	[-0.8%, -0.7%]	2
Improvements ✅ (secondary)	-2.2%	[-3.1%, -1.2%]	8
All ❌✅ (primary)	-0.7%	[-0.8%, -0.7%]	2

Binary size

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

Bootstrap: 667.402s -> 668.179s (0.12%)
Artifact size: 318.98 MiB -> 318.90 MiB (-0.02%)

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 319843a with merge 56d23c2...

[bors]

☀️ Try build successful - checks-actions
Build commit: 56d23c2 (56d23c24d45f6d6a5af9529a6d829f8b01b83abd)

[rust-timer]

Finished benchmarking commit (56d23c2): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

Results (primary -2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.5%	[-2.6%, -2.4%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-2.6%, -2.4%]	2

Cycles

Results (secondary -0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

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

Bootstrap: 666.65s -> 668.05s (0.21%)
Artifact size: 318.96 MiB -> 319.00 MiB (0.01%)

[lcnr]

this is unfortunately still not tracking the current hidden type for the opaque afaict: Projection(<T as Trait>::Assoc, impl Foo) should have a different result on the hidden type of impl Foo.

Have you tried entirely disabling the global cache, only using the one local to the current infcx if we're defining at least one opaque types?

[oli-obk]

That would require duplicating the cache data structures, but i'll give it a shot. Just disabling caching entirely was too bad to land #126024 (comment)

[oli-obk]

this is unfortunately still not tracking the current hidden type for the opaque afaict: Projection(<T as Trait>::Assoc, impl Foo) should have a different result on the hidden type of impl Foo.

Huh? only in reveal all mode, where it doesn't matter anyway. We don't use the hidden type in projections in the old solver iirc

[lcnr]

rust/compiler/rustc_trait_selection/src/traits/project.rs

Lines 271 to 276 in 2d28b63

	// Need to define opaque types to support nested opaque types like `impl Fn() -> impl Trait`
	match infcx.at(&obligation.cause, obligation.param_env).eq(
	DefineOpaqueTypes::Yes,
	normalized,
	actual,
	) {

[mk12]

CI is showing a merge conflict in src/starnix/kernel/runner/lib.rs. What base commit does it apply PICK_REFS on top of? https://fxrev.dev/1087892 was submitted at 4:33pm and rolled at 4:36pm PT, right around the same time as CI ran.

[tmandry]

@mk12 it's the one in build-fuchsia.sh.

Opened #128127 to bump the commit instead of using cherry picks.

[Kobzol]

#128127 was merged.

[oli-obk]

@bors r=lcnr

[bors]

📌 Commit 61b5e11 has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 61b5e11 with merge 2ccafed...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 2ccafed to master...

[rust-timer]

Finished benchmarking commit (2ccafed): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.4%	[1.6%, 5.5%]	6
Regressions ❌ (secondary)	3.1%	[0.4%, 5.4%]	11
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.4%	[1.6%, 5.5%]	6

Max RSS (memory usage)

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

Cycles

Results (primary 2.6%, secondary 4.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.6%	[1.1%, 4.3%]	6
Regressions ❌ (secondary)	4.4%	[2.0%, 5.7%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.6%	[1.1%, 4.3%]	6

Binary size

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

Bootstrap: 771.472s -> 772.807s (0.17%)
Artifact size: 328.92 MiB -> 328.91 MiB (-0.00%)

[oli-obk]

Hmm... I forgot to rerun perf... But, this PR does fix a lingering soundness issue that we just don't have a reproduction for. The caches are now sound, but not used globally if an item has opaques. That's obviously a bulldozing way of solving this issue, but I'm not sure we can fix it in a robust way in the old solver.

[pnkfelix]

Hmm... this PR claims that it fixes #119272 , but the ICE listed there is still occurring on nightly.

Is the idea that there is an unsoundness that is somehow being illustrated by the test case in that issue, and this PR is addressing that unsoundness (via a blunt hammer) while the ICE itself is still not addressed? (Or was the wrong issue simply linked here?)