-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Improve rendering of crate features via doc(cfg) #75330
Conversation
r? @ollie27 (rust_highfive has picked a reviewer for you, use r? to override) |
I like the idea, however I think it needs some improvements: with this new wording, we don't know anymore that it's linked to features, which sounds problematic to me. However, I don't really have much ideas on how to make it obvious. Maybe adding cc @rust-lang/rustdoc |
It does mention 'crate features' when you click on it, which seems pretty clear. Does it need to be on the index page too? It's already pretty cramped there. |
I was mostly referring to the second case, my bad. Currently it just shows some values with specific CSS but doesn't tell what it is. |
The whole "This is supported on" section is related to |
I strongly disagree here: it's "common" to have crates enabling features specifically on docs.rs so that the documentation is available in any case. So in my opinion, it's very important to make it clear to users that they need to use this feature if they want this item. However, like I said, I don't like the current rendering and I think improving it is a good idea. However I don't agree with the changes you proposed. On the "short doc" views (in modules typically) to be exact. |
We're very much not disagreeing then, I was at the forefront of the wave of For the shorthand, I think anything longer than this will be too long and more distracting than it's worth. As noted on the tracking issue:
@dtolnay it would be interesting to see if you still think so with this much more streamlined rendering? |
(I misspelled the mention first time, and not sure if github notifies based on edits). @dtolnay do you think the rendering here is streamlined enough to want it displayed on the index pages, or would you still want to disable it in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Nemo157, I think this is reasonable and I would be okay with this on the index page for Syn. Once the second issue in #43781 (comment) is addressed we'll start using this.
(I am planning to look into this one too once this change is merged). |
My concern still hasn't been addressed: docs are hard to read, removing all the information about it isn't a good idea I think. |
I still think it's fine to only have 'crate feature' on the item itself. You might not know the highlight is a feature the first time you read it on the index page, but it will be very clear after you click on the item and after that it will be better not to have the clutter. Maybe we could also have it display a 'This is a crate feature' tooltip on hover or something? |
That would be acceptable. |
Might be easier to have the full longform message in the tooltip? |
I'm shared on having the long title in the HTML directly: it's increasing the HTML size once again. Not a blocker for me though, but makes me sad. Do you have a display when you hover it by any chance? |
// @has 'foo/quux/index.html' | ||
// @matches '-' '//*[@class="module-item"]//*[@class="stab portability"]' '^sync and send and foo and bar$' | ||
// @has '-' '//*[@class="module-item"]//*[@class="stab portability"]/@title' 'This is supported on crate feature `sync` and crate feature `send` and `foo` and `bar` only' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this would be nicer as sync, send, foo, and bar
. But I think the existing behavior had this as well so not a blocker.
4a13357
to
3328bd9
Compare
This could be largely offset again by suppressing common |
What do you mean by "common |
The last screenshot there is from a module which already requires the |
I don't have strong opinions on this, the proposal looks fine but i'm excited to see if it can be improved. I'm going to unsubscribe while y'all discuss, feel free to tag me back in (or ping me elsewhere) if you want my opinion! |
This seems like a great improvement to me. @GuillaumeGomez did you have any concerns unresolved? If not I think this is good to merge. |
📌 Commit 3328bd9 has been approved by |
…albini Rollup of 12 pull requests Successful merges: - rust-lang#75330 (Improve rendering of crate features via doc(cfg)) - rust-lang#75927 (Use intra-doc links in `core::macros`) - rust-lang#75941 (Clean up E0761 explanation) - rust-lang#75943 (Fix potential UB in align_offset doc examples) - rust-lang#75946 (Error use explicit intra-doc link and fix text) - rust-lang#75955 (Use intra-doc links in `core::future::future` and `core::num::dec2flt`) - rust-lang#75967 (Fix typo in `std::hint::black_box` docs) - rust-lang#75972 (Fix ICE due to carriage return w/ multibyte char) - rust-lang#75989 (Rename rustdoc/test -> rustdoc/doctest) - rust-lang#75996 (fix wording in release notes) - rust-lang#75998 (Add InstrProfilingPlatformFuchsia.c to profiler_builtins) - rust-lang#76000 (Adds --bless support to test/run-make-fulldeps) Failed merges: r? @ghost
The current rendering of crate features with
doc(cfg(feature = ".."))
is verbose and unwieldy for users,doc(cfg(target_feature = ".."))
is special-cased to make it render nicely, and a similar rendering can be applied todoc(cfg(feature))
to make it easier for users to read.I also added special casing of
all
/any
cfgs consisting of justfeature
/target-feature
to remove the repetitive "target/crate feature" prefix.The downside of this current rendering is that there is no distinction between
feature
andtarget_feature
in the shorthand display. IMO this is ok, or if anythingtarget_feature
should have a more verbose shorthand, becausedoc(cfg(feature = ".."))
usage is going to vastly outstripdoc(cfg(target_feature = ".."))
usage in non-stdlib crates when it eventually stabilizes (or even before that given the number of crates usingcfg_attr(docsrs)
like constructs).Previously
Now
cc #43781