[libcore] Disable doc(auto_cfg) for integers trait impls - #154311
Merged
rust-bors[bot] merged 1 commit intoMar 25, 2026
Conversation
Collaborator
|
Some changes occurred in integer formatting cc @tgross35 |
rustbot
added
S-waiting-on-review
Collaborator
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
GuillaumeGomez
changed the title
doc(auto_cfg) for integers trait implsdoc(auto_cfg) for integers trait impls
eggyal
approved these changes
Mar 24, 2026
tgross35
approved these changes
Mar 24, 2026
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
I take that back, this only handles the traits. Removed. |
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Mar 24, 2026
…, r=eggyal,tgross35 [libcore] Disable `doc(auto_cfg)` for integers trait impls Fixes rust-lang#153655. Thanks to rust-lang#153964, `doc(auto_cfg)` finally works as expected on impls. So now this fix works: <img width="1000" height="806" alt="image" src="https://github.com/user-attachments/assets/f37da375-c2eb-4a7b-abf2-1fdd3a73e2bb" /> cc @eggyal
This was referenced Mar 24, 2026
github-actions Bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Mar 25, 2026
…uwer Rollup of 3 pull requests Successful merges: - rust-lang/rust#154311 ([libcore] Disable `doc(auto_cfg)` for integers trait impls) - rust-lang/rust#154331 (allow `incomplete_features` in all ui tests) - rust-lang/rust#154336 (Remove more BuiltinLintDiag variants - part 3)
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 24, 2026
…-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
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 24, 2026
…-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
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 25, 2026
…-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
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 25, 2026
…-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
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 25, 2026
…-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
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Jul 25, 2026
…-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
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Jul 25, 2026
…-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
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Jul 25, 2026
…-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
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Jul 25, 2026
…-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
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 26, 2026
…-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
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 26, 2026
…-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
rust-timer
added a commit
that referenced
this pull request
Jul 26, 2026
Rollup merge of #159819 - Vastargazing:fix/poison-error-auto-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 #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
pull Bot
pushed a commit
to xtqqczze/rust-lang-miri
that referenced
this pull request
Jul 27, 2026
…, 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/rust#153964, rust-lang/rust#154311, and rust-lang/rust#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/rust#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/rust#156426 (adding `#[doc(auto_cfg = false)]` to both variants) and adds a regression test to cover this pattern going forward. r? @GuillaumeGomez
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
5 participants
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.
Fixes #153655.
Thanks to #153964,
doc(auto_cfg)finally works as expected on impls. So now this fix works:cc @eggyal