Simplify doc-cfg rendering based on the current context #77672
Conversation
For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page, but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering, as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first.
|
r? @ollie27 (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
jyn514
added
A-rustdoc-ui
| cx: &Context, | ||
| item: &clean::Item, | ||
| is_hidden: bool, | ||
| parent: Option<&clean::Item>, |
There was a problem hiding this comment.
Is it intentional this only works with one level of nesting? I'm thinking of three nested modules, each requiring their own feature.
No problem if so, just wanted to make you'd thought of it
There was a problem hiding this comment.
The cfg in that case is pre-merged, if you look at the second screenshot above the feature="futures-io" cfg is coming from the async_compression::futures::bufread module, and the feature="brotli" cfg is coming from the BrotliDecoder, and these are merged into a single all(feature="futures-io", feature="brotli") cfg on BrotliDecoder. So for simple cases like this, the existing code merging these features down will handle nesting well (and I have yet to see any real code that wants to use non-simple cases).
There was a problem hiding this comment.
Oh nice! And you actually have test cases for this already, I missed them: https://github.com/rust-lang/rust/pull/77672/files#diff-dbdbc9d891c98a6926bc14ca63c97dfd6a73e8438692533d62eaa73bf32e8eccR169
There was a problem hiding this comment.
So for simple cases like this, the existing code merging these features down will handle nesting well (and I have yet to see any real code that wants to use non-simple cases).
That seems fine - if someone needs the complicated cases we can always add them in a follow-up, but I doubt it will come up.
|
@bors r+ |
|
📌 Commit 4409cb2 has been approved by |
bors
added
S-waiting-on-bors
Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page, but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering, as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots, left is current, right is new:      cc rust-lang#43781
Rollup of 14 pull requests Successful merges: - rust-lang#75023 (ensure arguments are included in count mismatch span) - rust-lang#75265 (Add `str::{Split,RSplit,SplitN,RSplitN,SplitTerminator,RSplitTerminator,SplitInclusive}::as_str` methods) - rust-lang#75675 (mangling: mangle impl params w/ v0 scheme) - rust-lang#76084 (Refactor io/buffered.rs into submodules) - rust-lang#76119 (Stabilize move_ref_pattern) - rust-lang#77493 (ICEs should always print the top of the query stack) - rust-lang#77619 (Use futex-based thread-parker for Wasm32.) - rust-lang#77646 (For backtrace, use StaticMutex instead of a raw sys Mutex.) - rust-lang#77648 (Static mutex is static) - rust-lang#77657 (Cleanup cloudabi mutexes and condvars) - rust-lang#77672 (Simplify doc-cfg rendering based on the current context) - rust-lang#77780 (rustc_parse: fix spans on cast and range exprs with attrs) - rust-lang#77935 (BTreeMap: make PartialCmp/PartialEq explicit and tested) - rust-lang#77980 (Fix intra doc link for needs_drop) Failed merges: r? `@ghost`
For sub-items on a page don't show cfg that has already been rendered on
a parent item. At its simplest this means not showing anything that is
shown in the portability message at the top of the page, but also for
things like fields of an enum variant if that variant itself is
cfg-gated then don't repeat those cfg on each field of the variant.
This does not touch trait implementation rendering, as that is more
complex and there are existing issues around how it deals with doc-cfg
that need to be fixed first.
Screenshots, left is current, right is new:
cc #43781