@@ -76,3 +76,55 @@ For more details, check out [the RFC][RFC 1946], and see [the tracking issue][43
76
76
information about what parts of the feature are available.
77
77
78
78
[ 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