rustdoc: decouple stability and const-stability #91694
Conversation
|
r? @ollie27 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| // Show const-stability even for unstable functions. | ||
| // @matches 'foo/struct.Bar.html' '//span[@class="since"]' '^const: 1.3.0$' | ||
| #[unstable(feature = "foo2", issue = "none")] | ||
| #[rustc_const_stable(feature = "rust1", since = "1.3.0")] |
There was a problem hiding this comment.
I think this is invalid, you cannot have a rustc_const_stable with an unstable attribute, but due to a bug in the compiler it's currently accepted despite being obviously wrong (cf. #79551).
There was a problem hiding this comment.
I disagree that it's "obviously wrong", allowing unstable functions to be called in a const-stable context is called out as a use-case in the rustc-guide.
There was a problem hiding this comment.
Fair enough, I didn't knew that. Thanks for that but I still think having both rustc_const_stable and unstable is "wrong" in a sense.
There was a problem hiding this comment.
I agree that unstable + rustc_const_stable doesn't make a lot of sense; stable functions can call unstable functions, so shouldn't rustc_const_stable functions be able to call rustc_const_unstable functions?
There was a problem hiding this comment.
Regardless of whether const-stable unstable functions are disallowed in the future, the implementation of this PR won't be affected: the invalid test case will just be removed.
For now, it's supported, so it makes sense to me to show it in the documentation.
apiraino
added
the
T-rustdoc
|
☔ The latest upstream changes (presumably #92719) made this pull request unmergeable. Please resolve the merge conflicts. |
euclio
force-pushed
the
stability-improvements
branch
from
5096afd to
dc1c39b
Compare
|
Rebased. |
|
|
||
| impl Bar { | ||
| // Do not show non-const stabilities that are the same as the enclosing item. | ||
| // @matches 'foo/struct.Bar.html' '//span[@class="since"]' '^const: 1.2.0$' |
There was a problem hiding this comment.
Is the 1.0.0 still displayed? If not, please put it back like it used to. In any case, please add a test to ensure both are displayed if both are present like it's currently the case.
There was a problem hiding this comment.
@GuillaumeGomez This is one of the goals of this PR. Currently, stabilities are omitted if the stability of the item matches the stability of the enclosing struct or module, except if they also have a const stability.
This PR updates the logic to always omit the stability if it matches, regardless of whether the item is const-stable or not.
There was a problem hiding this comment.
Oh I see. Thanks for the explanations!
|
Thanks! @bors: r+ |
|
📌 Commit dc1c39b has been approved by |
bors
added
S-waiting-on-bors
…askrgr Rollup of 13 pull requests Successful merges: - rust-lang#89747 (Add MaybeUninit::(slice_)as_bytes(_mut)) - rust-lang#89764 (Fix variant index / discriminant confusion in uninhabited enum branching) - rust-lang#91606 (Stabilize `-Z print-link-args` as `--print link-args`) - rust-lang#91694 (rustdoc: decouple stability and const-stability) - rust-lang#92183 (Point at correct argument when async fn output type lifetime disagrees with signature) - rust-lang#92582 (improve `_` constants in item signature handling) - rust-lang#92680 (intra-doc: Use the impl's assoc item where possible) - rust-lang#92704 (Change lint message to be stronger for &T -> &mut T transmute) - rust-lang#92861 (Rustdoc mobile: put out-of-band info on its own line) - rust-lang#92992 (Help optimize out backtraces when disabled) - rust-lang#93038 (Fix star handling in block doc comments) - rust-lang#93108 (:arrow_up: rust-analyzer) - rust-lang#93112 (Fix CVE-2022-21658) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This PR tweaks the stability rendering code to consider stability and const-stability separately. This fixes two issues:
Fixes #90552.