Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustdoc: skip stability inheritance for some item kinds #132481

Merged
merged 1 commit into from
Nov 2, 2024

Conversation

lukas-code
Copy link
Member

@lukas-code lukas-code commented Nov 2, 2024

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 i32 docs on core 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) #132440

@rustbot
Copy link
Collaborator

rustbot commented Nov 2, 2024

r? @notriddle

rustbot has assigned @notriddle.
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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Nov 2, 2024
@lukas-code
Copy link
Member Author

Nominating for beta, because #132440 is a regression to beta.

As always, we could also revert instead of backporting and considering that the author is clearly clueless and has already gotten this logic wrong twice before, reverting seems advisable 😸

@rustbot label beta-nominated

@rustbot rustbot added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Nov 2, 2024
Copy link
Member

@GuillaumeGomez GuillaumeGomez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

@GuillaumeGomez
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Nov 2, 2024

📌 Commit 728315d has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors 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 Nov 2, 2024
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
@bors bors merged commit 6eeb286 into rust-lang:master Nov 2, 2024
6 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Nov 2, 2024
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
@lukas-code lukas-code deleted the doc-stab3 branch November 2, 2024 16:58
@fmease
Copy link
Member

fmease commented Nov 2, 2024

Beta backport accepted as per Zulip poll.

@rustbot label beta-accepted

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Nov 2, 2024
@cuviper cuviper mentioned this pull request Nov 7, 2024
@cuviper cuviper modified the milestones: 1.84.0, 1.83.0 Nov 7, 2024
@cuviper cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Nov 7, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants