-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Tracking issue for #[doc(cfg(…))]
, #[doc(cfg_hide(…))]
and doc_auto_cfg
#43781
Comments
There are different implementations and signatures for `get_pollfd` depending on whether the target plateform is unix or windows. When generating the doc, we need both implementations to appear regardless of the target platform. This commit is inspired by the way Rust `std` library deals with `process::Command` OS dependent variants (https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt). Documentation can't be accurate though as we can't use the`std::os::windows` on `unix` and vice versa. As a workaround a fake fd class matching the other platform is declared. This could be further enhanced once `#[doc(cfg(...))]` is stabilized (rust-lang/rust#43781) by declaring `#[doc(cfg(unix))]` or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported on **Windows/Unix** only`. Unfortunately, these comments disappear when generating will `--all-features` because they are not part of the documentation in the gir file.
There are different implementations and signatures for `get_pollfd` depending on whether the target platform is unix or windows. When generating the doc, we need both implementations to appear regardless of the target platform. This commit is inspired by the way Rust `std` library deals with `process::Command` OS dependent variants (https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt). Documentation can't be accurate though as we can't use the`std::os::windows` on `unix` and vice versa. As a workaround a fake fd class matching the other platform is declared. This could be further enhanced once `#[doc(cfg(...))]` is stabilized (rust-lang/rust#43781) by declaring `#[doc(cfg(unix))]` or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported on **Windows/Unix** only`. Unfortunately, these comments disappear when generating will `--all-features` because they are not part of the documentation in the gir file.
There are different implementations and signatures for `get_pollfd` depending on whether the target platform is unix or windows. When generating the doc, we need both implementations to appear regardless of the target platform. This commit is inspired by the way Rust `std` library deals with `process::Command` OS dependent variants (https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt). Documentation can't be accurate though as we can't use the`std::os::windows` on `unix` and vice versa. As a workaround a fake fd class matching the other platform is declared. This could be further enhanced once `#[doc(cfg(...))]` is stabilized (rust-lang/rust#43781) by declaring `#[doc(cfg(unix))]` or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported on **Windows/Unix** only`. Unfortunately, these comments disappear when generating will `--all-features` because they are not part of the documentation in the gir file.
There are different implementations and signatures for `get_pollfd` depending on whether the target platform is unix or windows. When generating the doc, we need both implementations to appear regardless of the target platform. This commit is inspired by the way Rust `std` library deals with `process::Command` OS dependent variants (https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt). Documentation can't be accurate though as we can't use the`std::os::windows` on `unix` and vice versa. As a workaround a fake fd class matching the other platform is declared. This could be further enhanced once `#[doc(cfg(...))]` is stabilized (rust-lang/rust#43781) by declaring `#[doc(cfg(unix))]` or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported on **Windows/Unix** only`. Unfortunately, these comments disappear when generating will `--all-features` because they are not part of the documentation in the gir file.
There are different implementations and signatures for `get_pollfd` depending on whether the target platform is unix or windows. When generating the doc, we need both implementations to appear regardless of the target platform. This commit is inspired by the way Rust `std` library deals with `process::Command` OS dependent variants (https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt). Documentation can't be accurate though as we can't use the`std::os::windows` on `unix` and vice versa. As a workaround a fake fd class matching the other platform is declared. This could be further enhanced once `#[doc(cfg(...))]` is stabilized (rust-lang/rust#43781) by declaring `#[doc(cfg(unix))]` or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported on **Windows/Unix** only`. Unfortunately, these comments disappear when generating will `--all-features` because they are not part of the documentation in the gir file.
There are different implementations and signatures for `get_pollfd` depending on whether the target platform is unix or windows. When generating the doc, we need both implementations to appear regardless of the target platform. This commit is inspired by the way Rust `std` library deals with `process::Command` OS dependent variants (https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt). Documentation can't be accurate though as we can't use the`std::os::windows` on `unix` and vice versa. As a workaround a fake fd class matching the other platform is declared. This could be further enhanced once `#[doc(cfg(...))]` is stabilized (rust-lang/rust#43781) by declaring `#[doc(cfg(unix))]` or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported on **Windows/Unix** only`. Unfortunately, these comments disappear when generating will `--all-features` because they are not part of the documentation in the gir file.
|
I think that |
There is also the issue that it repeats every feature on every item in a page: When I last attempted to do something about rendering features I found it much more useful to separately keep track of "all required features" to render at the top of the items page and "newly introduced features" to render on the sub-items on the page, so you don't get this distracting repetition on every item. |
…c, r=QuietMisdreavus Stabilize cfg(doc) cc rust-lang#43781.
We tried out this feature in Syn (dtolnay/syn#734) and decided against using it yet. What I am happy withI like how the message turns out at the top of the doc page of a single type or function. We had previously displayed this information using an italicized note, which was less noticeable. What I am not happy withOur index page becomes extremely noisy. I wish there were a way to not show all of these in our case. It is enough to have this information on the type's individual page. Cfg combinations are not among the most important information to show on the index page. Also inheriting the same note onto every public field seems unnecessary in our use case. |
We'll need #103300 to be fixed beforehand as well. |
I noticed in gfx-rs/wgpu#4935 (comment) that it would be very nice if we could add custom names to rust/src/librustdoc/clean/cfg.rs Lines 488 to 590 in 2b1365b
Maybe something like |
I just found this doesn't appear to support |
|
It isn't, see #64796 |
This issue is 5 years old and doesn't seem to have been updated much since then. And the only place where the attribute is used is in std libs. However it can be used with a nightly rustc: #[cfg(version = "1.70.0")]
fn foo() {}
fn main() {} gives:
But in any case, until there is a clear position on whether or not this attribute should be rustc internal only or not, I don't think there is anything to be done. |
The issue I linked is literally a tracking issue for an accepted RFC. It's not internal, it's supposed to be usable in nightly with syntax |
@GuillaumeGomez frankly I have no idea what you're thinking of, but you're unquestionably confusing two different features. |
Likely yes... |
Just poking around: it appears that the |
The RFC (which is still under discussion so maybe not its final form) proposes something slightly different than what's currently implemented and adds more attributes to give more control. Currently, to enable this feature, you use |
This is a tracking issue for the
#[doc(cfg(…))]
attribute (feature:doc_cfg
) introduced in #43348 and#[doc(cfg_hide(…))]
(feature:doc_cfg_hide
) attribute introduced in #89596, along with thedoc_auto_cfg
feature introduced in #90502.Steps:
Fix syntax mismatches: Rustdoc and rustc accept different(fixed in Unify rustc and rustdoc parsing ofcfg
syntax #84437cfg()
#84442)(cc #1998)
The text was updated successfully, but these errors were encountered: