rustdoc: skip stability inheritance for some item kinds#132481
Merged
bors merged 1 commit intorust-lang:masterfrom Nov 2, 2024
Merged
rustdoc: skip stability inheritance for some item kinds#132481bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
Conversation
Collaborator
|
r? @notriddle rustbot has assigned @notriddle. Use |
rustbot
added
S-waiting-on-review
Member
Author
rustbot
added
the
beta-nominated
GuillaumeGomez
approved these changes
Nov 2, 2024
Member
GuillaumeGomez
left a comment
GuillaumeGomez
left a comment
There was a problem hiding this comment.
Looks good to me, thanks!
Member
|
@bors r+ rollup |
Collaborator
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 2, 2024
library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 2, 2024
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#132481 (rustdoc: skip stability inheritance for some item kinds) - rust-lang#132482 (library: fix some stability annotations) - rust-lang#132493 (Fix type reference in documents which was being confused with html tags.) - rust-lang#132494 (make `download-rustc="if-unchanged"` default for library profile) - rust-lang#132495 (Remove unintended link) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 2, 2024
Rollup merge of rust-lang#132482 - lukas-code:stab-attrs, r=Noratrieb library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 2, 2024
Rollup merge of rust-lang#132481 - lukas-code:doc-stab3, r=GuillaumeGomez rustdoc: skip stability inheritance for some item kinds For some item kinds it's incorrect to inherit their parent's stability, because they might be accessible without referring to the parent directly -- This PR removes the stability inheritance for these items and reverts their displayed stability to that before rust-lang#130798. Impl items, both inherent and trait impls, have a stability, but it is ignored when checking for enabled features. However, impl items are automatically unstable if they're nested inside an unstable module -- this caused the children of impl to inherit the instability and lead to rust-lang#132440. Furthermore, for associated items only the stability of the associated item itself is checked and not that of its parent impl. This is true even for trait impls and we have [relied on this behavior in the standard library in the past](https://doc.rust-lang.org/1.37.0/std/slice/trait.SliceConcatExt.html#tymethod.concat), so these also shouldn't inherit the impl's stability. I've also removed the stability inheritance for primitives and keywords so that viewing e.g. [the `i32` docs on `core`](https://doc.rust-lang.org/nightly/core/primitive.i32.html) will no longer show "since 1.6.0". Note that we currently don't annotate stability for the keyword docs, but if we start doing so in the future then this is probably more correct. fixes (after backport) rust-lang#132440
Member
|
Beta backport accepted as per Zulip poll. @rustbot label beta-accepted |
rustbot
added
the
beta-accepted
Merged
cuviper
removed
the
beta-nominated
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 8, 2024
[beta] backports - rustdoc: skip stability inheritance for some item kinds rust-lang#132481 - Avoid use imports in thread_local_inner! in static rust-lang#132101 - Also treat `impl` definition parent as transparent regarding modules rust-lang#132453 - Revert "Avoid nested replacement ranges" from rust-lang#129346. rust-lang#132587 r? cuviper
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 8, 2024
[beta] backports - rustdoc: skip stability inheritance for some item kinds rust-lang#132481 - Avoid use imports in thread_local_inner! in static rust-lang#132101 - Also treat `impl` definition parent as transparent regarding modules rust-lang#132453 - Revert "Avoid nested replacement ranges" from rust-lang#129346. rust-lang#132587 r? cuviper
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
7 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.
For some item kinds it's incorrect to inherit their parent's stability, because they might be accessible without referring to the parent directly -- This PR removes the stability inheritance for these items and reverts their displayed stability to that before #130798.
Impl items, both inherent and trait impls, have a stability, but it is ignored when checking for enabled features. However, impl items are automatically unstable if they're nested inside an unstable module -- this caused the children of impl to inherit the instability and lead to #132440.
Furthermore, for associated items only the stability of the associated item itself is checked and not that of its parent impl. This is true even for trait impls and we have relied on this behavior in the standard library in the past, so these also shouldn't inherit the impl's stability.
I've also removed the stability inheritance for primitives and keywords so that viewing e.g. the
i32docs oncorewill no longer show "since 1.6.0". Note that we currently don't annotate stability for the keyword docs, but if we start doing so in the future then this is probably more correct.fixes (after backport) #132440