Recover when attempting to force a query with unknown DefPathHash.

[cjgillot]

Fixes #90682
Fixes #90697
Fixes #90715
Fixes #90739
Fixes #91401

In the bugs above, the dep-graph attempts to force a dep-node whose DefPathHash is not known to the compiler. This causes an ICE because the query that refers to this DefPathHash should have been marked red.

This PR hides the bug by gracefully failing to force the query when this happens. I think this is the wrong solution to the problem. However, this has the merit of avoiding user-visible ICEs.

The right solution would be to find where the alien DefPathHash come from and to plug the information leak. I believe #85914 it responsible for a part.

r? @michaelwoerister

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 732dd13 with merge 7d7dd539439c1a9bcfe84fecb020cae61a1c2561...

[bors]

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

[rust-timer]

Queued 7d7dd539439c1a9bcfe84fecb020cae61a1c2561 with parent 0b42dea, future comparison URL.

[rust-timer]

Finished benchmarking commit (7d7dd539439c1a9bcfe84fecb020cae61a1c2561): comparison url.

Summary: This benchmark run did not return any relevant changes.

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. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

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

[ibraheemdev]

I believe this also fixes #91705, #91696, #91662, #91595, #91511, #90594, #90682, #89361, #89962, #45439, #90594, #89260, #89539, #91595.. and probably some others 😅

[michaelwoerister]

Thanks a lot for PR and the investigation, @cjgillot!
I'll try to review and think through the problem as soon as possible. I know we had these methods return Option<DefId> instead of DefId in the past.

[cjgillot]

@Aaron1011 does this PR fix the issue you diagnosed in #91696 (comment)? Or is the ice simply moved somewhere else?

Should we prefer wrapping try_load_from_on_disk_cache_in_memory in dep_graph.with_ignore?

[Aaron1011]

@cjgillot: Personally, I think silently suppressing this error is the wrong thing to do. Fixing the issue identified in #91696 (comment) should fix most of the cases of this - any remaining crashes will be a new issue which we'll want to be alerted of.

Should we prefer wrapping try_load_from_on_disk_cache_in_memory in dep_graph.with_ignore?

I think that would work, but I would prefer to avoid creating any new dep graph edges during the loading of queries.

[michaelwoerister]

OK, so the conclusion here is that we should rather fix the (now identified) underlying issue, that is, that queries invoked during cache loading are not handled correctly, right?