Skip to content

Commit 0f96e14

Browse files
talk about doc(cfg)
1 parent 30adb53 commit 0f96e14

File tree

1 file changed

+52
-0
lines changed

1 file changed

+52
-0
lines changed

src/doc/rustdoc/src/unstable-features.md

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -76,3 +76,55 @@ For more details, check out [the RFC][RFC 1946], and see [the tracking issue][43
7676
information about what parts of the feature are available.
7777

7878
[43466]: https://github.com/rust-lang/rust/issues/43466
79+
80+
## Documenting platform-/feature-specific information
81+
82+
Because of the way Rustdoc documents a crate, the documentation it creates is specific to the target
83+
rustc compiles for. Anything that's specific to any other target is dropped via `#[cfg]` attribute
84+
processing early in the compilation process. However, Rustdoc has a trick up its sleeve to handle
85+
platform-specific code if it *does* receive it.
86+
87+
Because Rustdoc doesn't need to fully compile a crate to binary, it replaces function bodies with
88+
`loop {}` to prevent having to process more than necessary. This means that any code within a
89+
function that requires platform-specific pieces is ignored. Combined with a special attribute,
90+
`#[doc(cfg(...))]`, you can tell Rustdoc exactly which platform something is supposed to run on,
91+
ensuring that doctests are only run on the appropriate platforms.
92+
93+
The `#[doc(cfg(...))]` attribute has another effect: When Rustdoc renders documentation for that
94+
item, it will be accompanied by a banner explaining that the item is only available on certain
95+
platforms.
96+
97+
As mentioned earlier, getting the items to Rustdoc requires some extra preparation. The standard
98+
library adds a `--cfg dox` flag to every Rustdoc command, but the same thing can be accomplished by
99+
adding a feature to your Cargo.toml and adding `--feature dox` (or whatever you choose to name the
100+
feature) to your `cargo doc` calls.
101+
102+
Either way, once you create an environment for the documentation, you can start to augment your
103+
`#[cfg]` attributes to allow both the target platform *and* the documentation configuration to leave
104+
the item in. For example, `#[cfg(any(windows, feature = "dox"))]` will preserve the item either on
105+
Windows or during the documentation process. Then, adding a new attribute `#[doc(cfg(windows))]`
106+
will tell Rustdoc that the item is supposed to be used on Windows. For example:
107+
108+
```rust
109+
#![feature(doc_cfg)]
110+
111+
/// Token struct that can only be used on Windows.
112+
#[cfg(any(windows, feature = "dox"))]
113+
#[doc(cfg(windows))]
114+
pub struct WindowsToken;
115+
116+
/// Token struct that can only be used on Unix.
117+
#[cfg(any(unix, feature = "dox"))]
118+
#[doc(cfg(unix))]
119+
pub struct UnixToken;
120+
```
121+
122+
In this sample, the tokens will only appear on their respective platforms, but they will both appear
123+
in documentation.
124+
125+
`#[doc(cfg(...))]` was introduced to be used by the standard library and is currently controlled by
126+
a feature gate. For more information, see [its chapter in the Unstable Book][unstable-doc-cfg] and
127+
[its tracking issue][issue-doc-cfg].
128+
129+
[unstable-doc-cfg]: ../unstable-book/language-features/doc-cfg.html
130+
[issue-doc-cfg]: https://github.com/rust-lang/rust/issues/43781

0 commit comments

Comments
 (0)