perf: Do not reevaluate goals on the changes on the very opaques registered by them

[ShoyuVanilla]

Originally written by @cynecx in rust-lang/rust-analyzer#23217 (comment)

Currently we track StalledOnOpaques with the number of opaques when we started to evaluate the goal.
This is correct and safe, but it makes the goals normalizes opaques, either by their own or their nested goals, to be evaluated once again b/c the num_opaques_in_storage is changed by themselves.

I think tracking the num_opaques_in_storage from the point we finished to evaluate the goal make sense, because..

• The only places we directly register opaques is when we evaluate Projection goals for opaques, and they are surely unaffected by skipping reevaluation.
• For the goals who have the above goals as nested goals are also unaffected, as registering some opaques from some nested goals still makes the other goals to be reevaluated in the fixed-point iteration.

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: b6ebf68 (b6ebf68a1faeb76a18761a2b1b04e6f5c915b129)
Base parent: edc52f8 (edc52f87c28f328c61685a02c47887a5cec7d767)

[rust-timer]

Finished benchmarking commit (b6ebf68): 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 rustc-perf
@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)	-4.3%	[-8.1%, -0.6%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.1%, secondary 1.8%)

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

	mean	range	count
Regressions ❌ (primary)	1.1%	[0.9%, 1.4%]	4
Regressions ❌ (secondary)	1.8%	[0.7%, 3.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[0.9%, 1.4%]	4

Cycles

Results (primary -3.4%, secondary -3.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)	3.9%	[3.9%, 3.9%]	1
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-4.4%	[-7.1%, -2.0%]	13
All ❌✅ (primary)	-3.4%	[-3.4%, -3.4%]	1

Binary size

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

Bootstrap: 472.928s -> 474.036s (0.23%)
Artifact size: 401.53 MiB -> 400.59 MiB (-0.23%)

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 4c748d4 (4c748d49e460d3fb6a13542b752f79ec75e03b4d)
Base parent: d8df826 (d8df82673d5911b6112a85bf91d9adefb2c66a1a)

[rust-timer]

Finished benchmarking commit (4c748d4): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

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.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.3%	[0.2%, 0.4%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.3%	[-8.1%, -0.5%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 2.6%)

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)	7.6%	[7.6%, 7.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -5.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)	-5.9%	[-7.1%, -3.8%]	5
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.0%	[0.0%, 0.1%]	15
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.1%]	15

Bootstrap: 477.112s -> 475.949s (-0.24%)
Artifact size: 401.86 MiB -> 401.00 MiB (-0.21%)

[amirHdev]

I'm still getting familiar with this part of the solver and I may be missing something here 🙂 but while following the shared InferCtxtLike changes I noticed that this adds num_opaques_in_storage as a required method while the rust-analyzer implementation doesn't seem to implement it yet

Since this originally came from the r-a slowdown would the corresponding r-a implementation helper need to be added here as well?