Rustdoc: group items by stability, rather than alphabetically #15345
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
Comments
|
Related to #8552 |
steveklabnik
added
the
C-enhancement
|
I'm going to close this in favor of #21674 as our stability story has changed pretty significantly since this was opened! |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 7, 2023
…-failure, r=Veykril Don't provide `add_missing_match_arms` assist when upmapping match arm list failed Fixes rust-lang#15310 We shouldn't provide the assist when we fail to find the original match arm list. Note that this PR will temporarily make the assist not applicable when attribute macro operates on the match expression in question, just like the case in rust-lang#15310, for most of the current stable toolchain users. This is because the sysroot-abi proc-macro-srv on the current stable [discards] spans for `Group` delimiters in some code paths, which the popular `proc-macro2` crate almost always calls, and it makes the identity of match arm list's brackets lost, leading to the upmapping failure. This has been fixed by rust-lang#14960, which will land in the next stable, 1.71. [discards]: https://github.com/rust-lang/rust/blob/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/src/tools/rust-analyzer/crates/proc-macro-srv/src/abis/abi_sysroot/ra_server.rs#L231
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Rustdoc has grown a lovely new feature whereby index pages with listings of functions and types will display a color next to each item indicating whether it's experimental, unstable, stable, or deprecated. I would like to go one further: group all items according to stability, rather than just having them scattered through an alphabetic list. After grouping by stability, I would like each of the four sections to be ordered as follows:
Within each group, ordering will remain alphabetical.
Reasoning: if I'm a user, I want to prefer stable items, which means that I want to see at a glance what my stable options are. If there are no stable options, then I want to consider unstable options, then experimental options, then deprecated options, in that order. Furthermore, if I'm a library author, then I want my users to consider options in the same order: stable first, then unstable-but-up-and-coming, then deprecated last.
The text was updated successfully, but these errors were encountered: