Allow recovering symbol_name query when there are no substs

[Aaron1011]

This is accomplished by creating a new symbol_name_for_plain_item
query, which is automatically called when symbol_name is invoked
with a supported key. The symbol_name_for_plain_item query just
uses a DefId as its argument, so it can be recovered.

[rust-highfive]

r? @petrochenkov

(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 86d3b47 with merge 99632a0f277a6b08405c1e1f9c9b5587840fdac4...

[bors]

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

[rust-timer]

Queued 99632a0f277a6b08405c1e1f9c9b5587840fdac4 with parent 8f3238f, future comparison URL.

[rust-timer]

Finished benchmarking commit (99632a0f277a6b08405c1e1f9c9b5587840fdac4): 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

[petrochenkov]

I'm missing the context here.

Is this extracted from some other PR?
I remember seeing something like this before.

What does "recovering" mean in this context?

[Aaron1011]

When a query input changes (i.e. the input gets marked red), the query system will try to re-run the query to see if the result is unchanged. If so, then the query can be marked green, even though one of its inputs is red.

The process of re-running the query is called 'forcing', and it depends on us being able to reconstruct the original query input ('recovery') to pass to the query. Currently, this is only supported for DefId/LocalDefId/CrateNum, since we use the DefPathHash as the DepNode hash.

We could try extending recovery to other query types, but that would require decoding of the type to be fallible (I think trying to decode a stale Ty will currently panic if some of the data is not present in the current session).

This was split out from #92204. However, I think #92533 is a much better approach (it's actually a perf improvement), so there's probably no need for this PR for the foreseeable future.

[petrochenkov]

Ok, this also seems to be a minor regression, so I'll keep this assigned to you for closing or doing something else.

[michaelwoerister]

You could try another perf run with cache_on_disk_if { true } for the new query.

[camelid]

triage: Hi, I'm closing this PR since it looks like that was already suggested due to perf issues, and it's been inactive for a while. Please feel free to re-open at any time if you'd like to work on it further!