-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Conversation
This file contains 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
r? @notriddle rustbot has assigned @notriddle. Use |
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
Some changes occurred in src/librustdoc/clean/types.rs cc @camelid |
This seems basically correct (also, it's totally unstable, so as long as nobody complains it should be fine). @bors r+ |
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
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)
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.
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.
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
orstd::net::IpAddr
intocore
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: