Lock shards while emitting depth limit error.

[ywxt]

Locking shards avoids collect_active_jobs isn't able to be completed during emitting depth limit error.

fix #142159

Zulip: https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/panic.20while.20depth_limit_error/with/554616169

cc @Zoxc

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Zoxc]

This looks fine to me.

[petrochenkov]

Could you add comments explaining why try_collect_active_jobs or collect_active_jobs is preferred in each specific case, and the general logic behind them - when we should choose one or another.

[petrochenkov]

I also don't like the amount of copypaste here.
The methods are not hot, they are only called in exceptional circumstances, from what I see.
So perhaps they could use an additional runtime boolean parameter telling whether to use lock_shards or try_lock_shards in the end, instead of duplicating code?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ywxt]

@rustbot ready

[petrochenkov]

r=me after some parameter renaming #148777 (comment)
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[ywxt]

@rustbot ready

[ywxt]

I don’t think I have permissions to interact with bors.

[petrochenkov]

Thanks!
@bors r+

[bors]

📌 Commit a4d0507 has been approved by petrochenkov

It is now in the queue for this repository.

[zetanumbers]

Assuming this PR introduced a perf regression for multiple threads, I wonder if fixing #146616 would allow us to revert this PR to gain that perf back. Just a thought.