std::sync::poison: disable auto_cfg on PoisonError::new by Vastargazing · Pull Request #159819 · rust-lang/rust

Vastargazing · 2026-07-24T08:17:02Z

PoisonError::new is defined twice, once for #[cfg(panic = "unwind")] and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration.

Currently, rustdoc's auto_cfg only looks at whichever cfg survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs.

This is the same auto_cfg limitation previously addressed in #153964, #154311, and #156426: when an item is split into mutually-exclusive cfg variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue #149786 pointed out PoisonError::new as another case of this pattern, but it hadn't been touched yet.

This PR applies the same fix as #156426 (adding #[doc(auto_cfg = false)] to both variants) and adds a regression test to cover this pattern going forward.

r? @GuillaumeGomez

PoisonError::new is defined twice, once under #[cfg(panic = "unwind")] and once under its negation, so exactly one definition exists in any given build. rustdoc's auto_cfg only sees whichever cfg survived expansion and tags the method as available under that cfg only, even though it is callable in every configuration - it just panics under panic=abort instead of returning. Disable auto_cfg on both variants so the portability note stops implying the method doesn't exist elsewhere. The doc comment already explains the panic=abort behavior in prose, so the cfg doesn't need to leak into the generated badge. Add a minimal regression test.

GuillaumeGomez · 2026-07-24T09:28:38Z

    /// or [`RwLock::read`](crate::sync::RwLock::read).
    ///
    /// This method may panic if std was built with `panic="abort"`.
+    #[doc(auto_cfg = false)]


I think #[doc(auto_cfg(hide(panic, any())))] would match better but that works too.

View changes since the review

GuillaumeGomez · 2026-07-24T09:30:18Z

r=me once CI pass

@bors delegate+

rust-bors · 2026-07-24T09:30:20Z

✌️ @Vastargazing, you can now approve this pull request!

If @GuillaumeGomez told you to "r=me" after making some further change, then please make that change and post @bors r=GuillaumeGomez.

View changes since this delegation.

Vastargazing · 2026-07-24T10:28:58Z

@bors r=GuillaumeGomez

rust-bors · 2026-07-24T10:29:02Z

📌 Commit f176d8b has been approved by GuillaumeGomez

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious CI failures

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

Rollup of 17 pull requests Successful merges: - #158168 (Added implementation on `set_permissions_nofollow` for all primary platforms) - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

Rollup of 16 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

Rollup of 20 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Lower paths to functions in const args as ConstKind::Error) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159877 (Revert "Export `derive` at `core::derive` and `std::derive`")

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

Rollup of 23 pull requests Successful merges: - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159204 (Add support to caller_location to rustc_public) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159810 (Add tuple never coercion collection regression test) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159877 (Revert "Export `derive` at `core::derive` and `std::derive`") - #159878 (bootstrap: Remove obsolete option `build.compiletest-use-stage0-libtest`) - #159882 (Update expect messages in library/alloc/boxed.rs and library/alloc/string.rs to follow the style guide) - #159891 (Split multiline derives into std/rustc macros) - #159895 (rustc-dev-guide subtree update)

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

Rollup of 23 pull requests Successful merges: - #159673 (bootstrap: forward -fdebug-prefix-map when using cc) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159204 (Add support to caller_location to rustc_public) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`) - #159810 (Add tuple never coercion collection regression test) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate) - #159853 (Updated expect messages for `CString` struct and method documentation) - #159878 (bootstrap: Remove obsolete option `build.compiletest-use-stage0-libtest`) - #159882 (Update expect messages in library/alloc/boxed.rs and library/alloc/string.rs to follow the style guide) - #159891 (Split multiline derives into std/rustc macros) - #159895 (rustc-dev-guide subtree update)

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

…uwer Rollup of 25 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Lower paths to functions in const args as ConstKind::Error) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159174 (Fix implicit_provenance_casts warnings on Xous) - #159179 (enable `unreachable_cfg_select_predicates` lint as part of `unused` lint group) - #159518 (iter: extend step_by specialization to cover StepBy<RangeIter<{integer}>>) - #159673 (bootstrap: forward -fdebug-prefix-map when using cc) - #159700 (Split non-local `semicolon_in_expressions_from_macros` into a separate lint) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159785 (Share _Unwind_Exception definition between native and wasm) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159204 (Add support to caller_location to rustc_public) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159695 (proc_macro: Fix cfg_attr inner attrs in file modules) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`)

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

…uwer Rollup of 25 pull requests Successful merges: - #159825 (codegen: handle OperandValue::Uninit in codegen_return_terminator) - #138618 (Support using const pointers in asm `const` operand) - #157962 (Lower paths to functions in const args as ConstKind::Error) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159174 (Fix implicit_provenance_casts warnings on Xous) - #159179 (enable `unreachable_cfg_select_predicates` lint as part of `unused` lint group) - #159518 (iter: extend step_by specialization to cover StepBy<RangeIter<{integer}>>) - #159673 (bootstrap: forward -fdebug-prefix-map when using cc) - #159700 (Split non-local `semicolon_in_expressions_from_macros` into a separate lint) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159738 (implement `CovariantUnsafeCell`) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159204 (Add support to caller_location to rustc_public) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159676 (Update wasm-component-ld to 0.5.27) - #159695 (proc_macro: Fix cfg_attr inner attrs in file modules) - #159730 (allow accessing the contents of UnsafeCell without going through get) - #159809 (Avoid `#[target_features]`)

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

@GuillaumeGomez

…-cfg-note, r=GuillaumeGomez std::sync::poison: disable auto_cfg on PoisonError::new `PoisonError::new` is defined twice, once for `#[cfg(panic = "unwind")]` and once for its negation. While exactly one definition survives expansion in any given build, the method itself is actually present in every configuration. Currently, rustdoc's `auto_cfg` only looks at whichever `cfg` survived expansion and tags the method accordingly, generating a misleading "Available on panic=unwind only" portability badge in the docs. This is the same `auto_cfg` limitation previously addressed in rust-lang#153964, rust-lang#154311, and rust-lang#156426: when an item is split into mutually-exclusive `cfg` variants that collectively cover all builds, rustdoc incorrectly marks it as conditionally available. Issue rust-lang#149786 pointed out `PoisonError::new` as another case of this pattern, but it hadn't been touched yet. This PR applies the same fix as rust-lang#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez

rustbot assigned GuillaumeGomez Jul 24, 2026

GuillaumeGomez reviewed Jul 24, 2026

View reviewed changes

GuillaumeGomez approved these changes Jul 24, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2026

jhpratt mentioned this pull request Jul 24, 2026

Rollup of 18 pull requests #159871

Closed

jhpratt mentioned this pull request Jul 24, 2026

Rollup of 17 pull requests #159872

Closed

jhpratt mentioned this pull request Jul 25, 2026

Rollup of 16 pull requests #159876

Closed

jhpratt mentioned this pull request Jul 25, 2026

Rollup of 19 pull requests #159879

Closed

jhpratt mentioned this pull request Jul 25, 2026

Rollup of 20 pull requests #159888

Closed

GuillaumeGomez mentioned this pull request Jul 25, 2026

Rollup of 23 pull requests #159903

Closed

GuillaumeGomez mentioned this pull request Jul 25, 2026

Rollup of 23 pull requests #159905

Closed

JonathanBrouwer mentioned this pull request Jul 25, 2026

Rollup of 25 pull requests #159920

Closed

JonathanBrouwer mentioned this pull request Jul 25, 2026

Rollup of 25 pull requests #159926

Closed

jhpratt mentioned this pull request Jul 26, 2026

Rollup of 25 pull requests #159941

Closed

jhpratt mentioned this pull request Jul 26, 2026

Rollup of 25 pull requests #159942

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

std::sync::poison: disable auto_cfg on PoisonError::new#159819

std::sync::poison: disable auto_cfg on PoisonError::new#159819
Vastargazing wants to merge 1 commit into
rust-lang:mainfrom
Vastargazing:fix/poison-error-auto-cfg-note

Vastargazing commented Jul 24, 2026 •

edited by rustbot

Loading

Uh oh!

GuillaumeGomez Jul 24, 2026 •

edited by rustbot

Loading

Uh oh!

GuillaumeGomez commented Jul 24, 2026

Uh oh!

rust-bors Bot commented Jul 24, 2026

Uh oh!

Vastargazing commented Jul 24, 2026

Uh oh!

rust-bors Bot commented Jul 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

Vastargazing commented Jul 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeGomez Jul 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez commented Jul 24, 2026

Uh oh!

rust-bors Bot commented Jul 24, 2026

Uh oh!

Vastargazing commented Jul 24, 2026

Uh oh!

rust-bors Bot commented Jul 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Vastargazing commented Jul 24, 2026 •

edited by rustbot

Loading

GuillaumeGomez Jul 24, 2026 •

edited by rustbot

Loading