Use EvaluatedToOkModuloRegions whenever we erase regions

[Aaron1011]

Fixes #80691

When we evaluate a trait predicate, we convert an
EvaluatedToOk result to EvaluatedToOkModuloRegions if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so EvaluatedToOk may not be correct for other predicates
that have the same cache key.

[rust-highfive]

r? @davidtwco

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

[Aaron1011]

cc @nikomatsakis @eddyb @matthewjasper

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 8f40b09ff6658df40bce0f4d2f69405d9359fd31 with merge ae47118b087e92eb4278a213096c4912eb626f06...

[bors]

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

[bors]

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

[rust-timer]

Queued ae47118b087e92eb4278a213096c4912eb626f06 with parent 0ce0fed, future comparison URL.

[rust-timer]

Finished benchmarking try commit (ae47118b087e92eb4278a213096c4912eb626f06): 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

[jackh726]

This makes sense to me. Am I correct in that this should only cause us to not be able to cache things that we were before? (I.e. we could be more conservative here than we need and its fine; it's only going the other way that we have to be extra careful). I haven't really looked at this code, so I don't know what the effect of module regions or not.

[Aaron1011]

Am I correct in that this should only cause us to not be able to cache things that we were before?

We still cache something in every case where we were previously caching - however, we now store EvaluatedToOkModuloRegions in some cases where we previously would have stored EvaluatedToOk.

I.e. we could be more conservative here than we need and its fine

That's my understanding, though I'd like to get someone more familiar with this code to confirm that. IIUC, it would be sound to delete EvaluatedToOk entirely, and only ever use EvaluatedToOkModuloRegions - however, that would be less efficient.

[nikomatsakis]

r? @nikomatsakis

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 31b35337591568f47e9580d36d931348584b8131 with merge eeb5a70d1b31f72580d95160f43b16018ac19482...

[bors]

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

[rust-timer]

Finished benchmarking try commit (eeb5a70d1b31f72580d95160f43b16018ac19482): 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

[nikomatsakis]

Performance seems reasonable.

[Aaron1011]

@bors r=nikomatsakis

[bors]

📌 Commit 102b578 has been approved by nikomatsakis

[bors]

⌛ Testing commit 102b578 with merge 07e0e2e...

[bors]

☀️ Test successful - checks-actions
Approved by: nikomatsakis
Pushing 07e0e2e to master...

[rylev]

@nikomatsakis @Aaron1011 Can you talk a bit more about why the performance regression seems reasonable? A performance hit of 2.8%, while not terrible, is certainly something we would want to discuss before writing off.

[nikomatsakis]

@rylev fair! Perhaps my thresholds are off.

I was motivated to land this mainly because it seemed reasonable and there were a number of problems being reported that it aims to address. However I'd be ok to revert and dig a bit deeper to see if there's an alternate solution with less performance impact.

One question I do have is that I'm not sure what gave rise to those problems, as this doesn't seem to be related to any new change (i.e., this caching logic etc has been in place a long time).

[Aaron1011]

One question I do have is that I'm not sure what gave rise to those problems, as this doesn't seem to be related to any new change (i.e., this caching logic etc has been in place a long time).

I think this issue has always exited - when #83007 landed, we started getting ICEs for a lot of issues that were silently causing results to change in incremental compilation.

[Mark-Simulacrum]

Yeah, as a correctness fix I think hit here is OK

[jonas-schievink]

#83115 is now on stable, so nominating this for backport

[Aaron1011]

@jonas-schievink: I think the issue people are hitting on stable is #83538 (but I'm not sure).

[jonas-schievink]

Yeah, I'm also hitting the issue on beta...