Repository navigation
Make Proxy weak reference as it seems that it is not dropped at all - #165676
Merged
rust-bors[bot] merged 1 commit intoNov 9, 2026
Merged
rust-bors[bot] merged 1 commit into
rust-bors[bot] merged 1 commit into
Conversation
rustbot
added
S-waiting-on-review
Contributor
|
@bors r+ rollup |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
rust-bors Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
…uwer Rollup of 9 pull requests Successful merges: - #165161 (`rustc_builtin_macros` cleanup, part 9) - #165663 (Avoid repeated gated spans snapshots during macro matching) - #165637 (library: std: process: Make Command::status platform specific) - #163571 ([rustdoc] Render `Deref` methods on aliased items) - #164712 (Reject unexpanded attributes in attributes) - #165516 (Point at array length instead of whole array type) - #165674 (Add regression test for issue 118449) - #165676 (Make `Proxy` weak reference as it seems that it is not dropped at all) - #165695 (Add regression test for unsafe diagnostic attributes)
rust-bors Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
Rollup merge of #165676 - aerooneqq:make-proxy-weak-reference-in-helper-thread, r=petrochenkov Make `Proxy` weak reference as it seems that it is not dropped at all Split from #165506 which makes `Proxy` droppable, which locally fixes the issue: ```rust thread 'jobserver::jobserver_and_j' (126990) panicked at src/tools/cargo/tests/testsuite/jobserver.rs:411:10: ---- expected: tests/testsuite/jobserver.rs:405:27 ++++ actual: stderr 1 1 | [WARNING] a `-j` argument was passed to Cargo but Cargo is also configured with an external jobserver in its environment, ignoring the `-j` parameter 2 2 | [COMPILING] foo v0.0.1 ([ROOT]/foo) 3 3 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s 4 + make[1]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! ``` (see #162848 (comment)). r? @petrochenkov
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Nov 12, 2026
…hread, r=petrochenkov Explicitly drop job server helper thread An adaptation of an LLM patch that was generated in https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/with/639482582. The original patch consisted from two fixes: explicit drop of a helper thread and additional logic for job server token request counting. This PR implements only the explicit drop part as I don't see how additional requests counting logic should help the issue. This reworks rust-lang#165676, as the [rationale](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/near/639152114) behind explicit drop of a helper thread seems reasonable for me: > From my rough understanding, while helper is handling a token, its upgrade() is often the last strong ref I guess. So, when run_in_thread_pool_with_globals returns and rustc exits, the token may still be in helper's hands. This fix didn't fail after several launches in rust-lang#165506 and locally. r? @petrochenkov
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Nov 12, 2026
…hread, r=petrochenkov Explicitly drop job server helper thread An adaptation of an LLM patch that was generated in https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/with/639482582. The original patch consisted from two fixes: explicit drop of a helper thread and additional logic for job server token request counting. This PR implements only the explicit drop part as I don't see how additional requests counting logic should help the issue. This reworks rust-lang#165676, as the [rationale](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/near/639152114) behind explicit drop of a helper thread seems reasonable for me: > From my rough understanding, while helper is handling a token, its upgrade() is often the last strong ref I guess. So, when run_in_thread_pool_with_globals returns and rustc exits, the token may still be in helper's hands. This fix didn't fail after several launches in rust-lang#165506 and locally. r? @petrochenkov
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Nov 12, 2026
…hread, r=petrochenkov Explicitly drop job server helper thread An adaptation of an LLM patch that was generated in https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/with/639482582. The original patch consisted from two fixes: explicit drop of a helper thread and additional logic for job server token request counting. This PR implements only the explicit drop part as I don't see how additional requests counting logic should help the issue. This reworks rust-lang#165676, as the [rationale](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/near/639152114) behind explicit drop of a helper thread seems reasonable for me: > From my rough understanding, while helper is handling a token, its upgrade() is often the last strong ref I guess. So, when run_in_thread_pool_with_globals returns and rustc exits, the token may still be in helper's hands. This fix didn't fail after several launches in rust-lang#165506 and locally. r? @petrochenkov
rust-bors Bot
pushed a commit
that referenced
this pull request
Nov 12, 2026
Rollup merge of #165854 - aerooneqq:explicitly-drop-helper-thread, r=petrochenkov Explicitly drop job server helper thread An adaptation of an LLM patch that was generated in https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/with/639482582. The original patch consisted from two fixes: explicit drop of a helper thread and additional logic for job server token request counting. This PR implements only the explicit drop part as I don't see how additional requests counting logic should help the issue. This reworks #165676, as the [rationale](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Interaction.20of.20Cargo.20jobserver.20tests.20and.20parallel.20frontend/near/639152114) behind explicit drop of a helper thread seems reasonable for me: > From my rough understanding, while helper is handling a token, its upgrade() is often the last strong ref I guess. So, when run_in_thread_pool_with_globals returns and rustc exits, the token may still be in helper's hands. This fix didn't fail after several launches in #165506 and locally. r? @petrochenkov
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split from #165506 which makes
Proxydroppable, which locally fixes the issue:(see #162848 (comment)).
r? @petrochenkov