Preserve most sub-obligations in the projection cache

[Aaron1011]

Fixes #85360

When we evaluate a projection predicate, we may produce sub-obligations. During trait evaluation, evaluating these sub-obligations might cause us to produce EvaluatedToOkModuloRegions.

When we cache the result of projection in our projection cache, we try to throw away some of the sub-obligations, so that we don't need to re-evaluate/process them the next time we need to perform this particular projection. However, we may end up throwing away predicates that will (recursively) evaluate to EvaluatedToOkModuloRegions. If we do, then the result of evaluating a predicate will depend on the state of the predicate cache - this is global untracked state, which interacts badly with incremental compilation.

To fix this, we now only discard global predicates that evaluate to EvaluatedToOk. This ensures that any predicates that (may) evaluate to EvaluatedToOkModuloRegions are kept in the cache, and influence the results of any queries which perform this projection.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit a3a287b0bfe095e1fd9bd4292a0e94f738a94cce with merge fa0462d22926332548181c1cd602c85dbb20fec8...

[bors]

☀️ Try build successful - checks-actions
Build commit: fa0462d22926332548181c1cd602c85dbb20fec8 (fa0462d22926332548181c1cd602c85dbb20fec8)

[rust-timer]

Queued fa0462d22926332548181c1cd602c85dbb20fec8 with parent 6a3dce9, future comparison URL.

[rust-timer]

Finished benchmarking try commit (fa0462d22926332548181c1cd602c85dbb20fec8): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit a3a287b0bfe095e1fd9bd4292a0e94f738a94cce with merge d246c813ecc8de89cc5a05b9479dac8195a3e251...

[bors]

☀️ Try build successful - checks-actions
Build commit: d246c813ecc8de89cc5a05b9479dac8195a3e251 (d246c813ecc8de89cc5a05b9479dac8195a3e251)

[rust-timer]

Queued d246c813ecc8de89cc5a05b9479dac8195a3e251 with parent d4e7cb3, future comparison URL.

[rust-timer]

Finished benchmarking try commit (d246c813ecc8de89cc5a05b9479dac8195a3e251): comparison url.

Summary: This change led to significant regressions 😿 in compiler performance.

• Very large regression in instruction counts (up to 21.4% on full builds of deeply-nested-check)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[rustbot]

Error: Label perf-regression can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit fbfe5baaf5d5faff7450209c02a699ad25948230 with merge 7d3788b67103a424bf6612495afedb80c4fe8b10...

[bors]

⌛ Testing commit 611191f with merge 371f3cd...

[bors]

☀️ Test successful - checks-actions
Approved by: jackh726
Pushing 371f3cd to master...

[pnkfelix]

@nikomatsakis: This PR is now ready for review.

This performance is worse than the two other approaches (#86896 and #86871), but this is less hacky, and more clearly correct.

As expected, this was flagged as causing mixed performance changes in instruction counts during weekly performance triage. Since these changes in performance were anticipating and discussed above, I'm marking as already-triaged.

Update: whoops, it was already marked accordingly. Sorry for the noise!

[apiraino]

It's already in current beta (Zulip comment)

@rustbot label -beta-nominated

[jackh726]

Do we want to nominate for stable? How concerned are we about this incremental issue? @rust-lang/compiler