get rid of tcx in deadlock handler when parallel compilation

[SparrowLii]

This is a very obscure and hard-to-trace problem that affects thread scheduling. If we copy tcx to the deadlock handler thread, it will perform unpredictable behavior and cause very weird problems when executing try_collect_active_jobs(For example, the deadlock handler thread suddenly preempts the content of the blocked worker thread and executes the unknown judgment branch, like #94654).
Fortunately we can avoid this behavior by precomputing query_map. This change fixes the following ui tests failure on my environment when set parallel-compiler = true:

    [ui] src/test\ui\async-await\no-const-async.rs
    [ui] src/test\ui\infinite\infinite-struct.rs
    [ui] src/test\ui\infinite\infinite-tag-type-recursion.rs
    [ui] src/test\ui\issues\issue-3008-1.rs
    [ui] src/test\ui\issues\issue-3008-2.rs
    [ui] src/test\ui\issues\issue-32326.rs
    [ui] src/test\ui\issues\issue-57271.rs
    [ui] src/test\ui\issues\issue-72554.rs
    [ui] src/test\ui\parser\fn-header-semantic-fail.rs
    [ui] src/test\ui\union\union-nonrepresentable.rs

Updates #75760
Fixes #94654

[rust-highfive]

r? @michaelwoerister

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

[cjgillot]

Thanks @SparrowLii. That's a great solution.
Could you remove try_collect_active_jobs from the QueryContext trait and make it an inherent method on QueryCtxt?

[SparrowLii]

Could you remove try_collect_active_jobs from the QueryContext trait and make it an inherent method on QueryCtxt?

Sure, made the corresponding changes.

#[Edit] It's a bit difficult to remove it from the QueryContext as try_start function call it when encounter cycle error
in serial compilation. Do we still need to do this?

[SparrowLii]

Umm.. seems that rustc_query_system still needs try_collect_active_jobs to exist in QueryContext: https://github.com/rust-lang/rust/runs/7084788737?check_suite_focus=true.

Just reverted the last change

[cjgillot]

Why is this pub required?

[SparrowLii]

We need to use try_collect_active_jobs and deadlock in rustc_interface::util::handle_deadlock. We can add pub use rustc_query_system::query::{deadlock, QueryContext} instead of pub the all thing here.

[cjgillot]

@bors r+ rollup=never

[bors]

📌 Commit fbca21e has been approved by cjgillot

[Zoxc]

If you're going to do significant work in handle_deadlock (which is called while Rayon's sleep lock is held), you might as well run the entire deadlock handler there and avoid the thread spawning.

An alternative way to fix #94654 would be to extend WorkerLocal to also work on the deadlock handler thread, as it currently expects to only be used on Rayon's threads.

[bors]

⌛ Testing commit fbca21e with merge 8c52a83...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 8c52a83 to master...

[rust-timer]

Finished benchmarking commit (8c52a83): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvement found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-2.4%	-2.4%	1
All 😿🎉 (primary)	N/A	N/A	0

Cycles

Results

• Primary benchmarks: 🎉 relevant improvement found
• Secondary benchmarks: no relevant changes found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-2.0%	-2.0%	1
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	-2.0%	-2.0%	1

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

@rustbot label: -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²