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: inherit parent's stability where applicable #130798

Merged
merged 1 commit into from
Sep 25, 2024

Conversation

lukas-code
Copy link
Member

It is currently not possible for a re-export to have a different stability (#30827). Therefore the standard library uses a hack when moving items like std::error::Error or std::net::IpAddr into core by marking the containing module (core::error / core::net) as unstable or stable in a later version than the items the module contains.

Previously, rustdoc would always show the stability as declared for an item rather than the stability as publicly reachable (i.e. the features required to actually access the item), which could be confusing when viewing the docs. This PR changes it so that we show the stability of the first unstable parent or the most recently stabilized parent instead, to hopefully make things less confusing.

fixes #130765

screenshots:
error in std error in core

@rustbot
Copy link
Collaborator

rustbot commented Sep 24, 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-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Sep 24, 2024
@rustbot
Copy link
Collaborator

rustbot commented Sep 24, 2024

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

@notriddle
Copy link
Contributor

This seems basically correct (also, it's totally unstable, so as long as nobody complains it should be fine).

@bors r+

@bors
Copy link
Contributor

bors commented Sep 24, 2024

📌 Commit 2fdeb3b has been approved by notriddle

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 Sep 24, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 25, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#130234 (improve compile errors for invalid ptr-to-ptr casts with trait objects)
 - rust-lang#130752 (Improve assembly test for CMSE ABIs)
 - rust-lang#130764 (Separate collection of crate-local inherent impls from error tracking)
 - rust-lang#130788 (Pin memchr to 2.5.0 in the library rather than rustc_ast)
 - rust-lang#130789 (add InProgress ErrorKind gated behind io_error_inprogress feature)
 - rust-lang#130793 (Mention `COMPILETEST_VERBOSE_CRASHES` on crash test failure)
 - rust-lang#130798 (rustdoc: inherit parent's stability where applicable)

Failed merges:

 - rust-lang#130735 (Simple validation for unsize coercion in MIR validation)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 9737f92 into rust-lang:master Sep 25, 2024
6 checks passed
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 25, 2024
Rollup merge of rust-lang#130798 - lukas-code:doc-stab, r=notriddle

rustdoc: inherit parent's stability where applicable

It is currently not possible for a re-export to have a different stability (rust-lang#30827). Therefore the standard library uses a hack when moving items like `std::error::Error` or `std::net::IpAddr` into `core` by marking the containing module (`core::error` / `core::net`) as unstable or stable in a later version than the items the module contains.

Previously, rustdoc would always show the *stability as declared* for an item rather than the *stability as publicly reachable* (i.e. the features required to actually access the item), which could be confusing when viewing the docs. This PR changes it so that we show the stability of the first unstable parent or the most recently stabilized parent instead, to hopefully make things less confusing.

fixes rust-lang#130765

screenshots:
![error in std](https://github.com/user-attachments/assets/2ab9bdb9-ed81-4e45-a832-ac7d3ba1be3f) ![error in core](https://github.com/user-attachments/assets/46f46182-5642-4ac5-b92e-0b99a8e2496d)
@rustbot rustbot added this to the 1.83.0 milestone Sep 25, 2024
@lukas-code lukas-code deleted the doc-stab branch September 25, 2024 11:42
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 25, 2024
rustdoc perf: clone `clean::Item` less

In rust-lang#130798, I caused a small perf regression for rustdoc (see rust-lang#130807 (comment)), so here is a small improvement to make up for it 😺.

r? ghost
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 27, 2024
…iddle

rustdoc perf: clone `clean::Item` less

In rust-lang#130798, I caused a small perf regression for rustdoc (see rust-lang#130807 (comment)), so here is a small improvement to make up for it 😺.

This change is actually unrelated to the minor perf regression in `Item::stability` and instead fixes a more relevant perf problem that I found while investigating: For certain crates with many impls on type aliases, we unnecessarily cloned large `clean::Item`s multiple times -- now we just borrow them.
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 27, 2024
…iddle

rustdoc perf: clone `clean::Item` less

In rust-lang#130798, I caused a small perf regression for rustdoc (see rust-lang#130807 (comment)), so here is a small improvement to make up for it 😺.

This change is actually unrelated to the minor perf regression in `Item::stability` and instead fixes a more relevant perf problem that I found while investigating: For certain crates with many impls on type aliases, we unnecessarily cloned large `clean::Item`s multiple times -- now we just borrow them.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 1, 2024
rustdoc: rewrite stability inheritance as a doc pass

Since doc inlining can almost arbitrarily change the module hierarchy, we can't just use the HIR ancestors of an item to compute its effective stability. This PR moves the stability inheritance that I implemented in rust-lang#130798 into a new doc pass `propagate-stability` that runs after doc inlining and uses the post-inlining ancestors of an item to correctly compute its effective stability.

fixes rust-lang#131020

r? `@notriddle`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 2, 2024
…omez

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
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. 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.

core::error::Error has incorrect stabilization version
4 participants