/rust

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(...))]` #43781

Open
kennytm opened this Issue Aug 10, 2017 · 0 comments

Comments

Assignees
No one assigned
Labels
C-tracking-issue T-rustdoc
Projects
None yet
Milestone
No milestone
3 participants
@kennytm @Mark-Simulacrum @QuietMisdreavus
@kennytm
Member

kennytm commented Aug 10, 2017

This is a tracking issue for the #[doc(cfg(...))] attribute introduced in #43348.

Steps:

(cc #1998)

@kennytm kennytm referenced this issue Aug 10, 2017

Merged

Expose all OS-specific modules in libstd doc. #43348

@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue T-dev-tools labels Aug 10, 2017

@kennytm kennytm added T-dev-tools-rustdoc and removed T-dev-tools labels Oct 21, 2017

fengalin added a commit to fengalin/gstreamer-rs that referenced this issue Mar 17, 2018

@fengalin
Bus::get_pollfd generate doc for both unix & windows 
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.
89293e3

fengalin added a commit to fengalin/gstreamer-rs that referenced this issue Mar 17, 2018

@fengalin
Bus::get_pollfd generate doc for both unix & windows 
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.
1dfcc0c

@fengalin fengalin referenced this issue Mar 17, 2018

Merged

Bus::get_pollfd generate doc for both unix & windows #95

fengalin added a commit to fengalin/gstreamer-rs that referenced this issue Mar 18, 2018

@fengalin
Bus::get_pollfd generate doc for both unix & windows 
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.
81907d8

fengalin added a commit to fengalin/gstreamer-rs that referenced this issue Mar 19, 2018

@fengalin
Bus::get_pollfd generate doc for both unix & windows 
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.
bca061d

sdroege added a commit to sdroege/gstreamer-rs that referenced this issue Mar 19, 2018

@fengalin @sdroege
Bus::get_pollfd generate doc for both unix & windows 
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.
Loading status checks…
cd56d60

@TheDan64 TheDan64 referenced this issue Mar 29, 2018

Open

Documention #2

22 of 47 tasks complete

@QuietMisdreavus QuietMisdreavus added T-rustdoc and removed T-rustdoc labels May 15, 2018

charlie-ht added a commit to charlie-ht/gstreamer-rs that referenced this issue Oct 28, 2018

@fengalin @charlie-ht
Bus::get_pollfd generate doc for both unix & windows 
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.
5e8c7d4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment