@@ -43,28 +43,16 @@ plain text.
43
43
These features operate by extending the ` #[doc] ` attribute, and thus can be caught by the compiler
44
44
and enabled with a ` #![feature(...)] ` attribute in your crate.
45
45
46
- ### Documenting platform-/feature-specific information
46
+ ### ` #[doc(cfg)] ` : Recording what platforms or features are required for code to be present
47
47
48
- Because of the way Rustdoc documents a crate, the documentation it creates is specific to the target
49
- rustc compiles for. Anything that's specific to any other target is dropped via ` #[cfg] ` attribute
50
- processing early in the compilation process. However, Rustdoc has a trick up its sleeve to handle
51
- platform-specific code if it * does* receive it.
48
+ You can use ` #[doc(cfg(...))] ` to tell Rustdoc exactly which platform items appear on.
49
+ This has two effects:
52
50
53
- Because Rustdoc doesn't need to fully compile a crate to binary, it replaces function bodies with
54
- ` loop {} ` to prevent having to process more than necessary. This means that any code within a
55
- function that requires platform-specific pieces is ignored. Combined with a special attribute,
56
- ` #[doc(cfg(...))] ` , you can tell Rustdoc exactly which platform something is supposed to run on,
57
- ensuring that doctests are only run on the appropriate platforms.
58
-
59
- The ` #[doc(cfg(...))] ` attribute has another effect: When Rustdoc renders documentation for that
60
- item, it will be accompanied by a banner explaining that the item is only available on certain
61
- platforms.
62
-
63
- For Rustdoc to document an item, it needs to see it, regardless of what platform it's currently
64
- running on. To aid this, Rustdoc sets the flag ` #[cfg(doc)] ` when running on your crate.
65
- Combining this with the target platform of a given item allows it to appear when building your crate
66
- normally on that platform, as well as when building documentation anywhere.
51
+ 1 . doctests will only run on the appropriate platforms, and
52
+ 2 . When Rustdoc renders documentation for that item, it will be accompanied by a banner explaining
53
+ that the item is only available on certain platforms.
67
54
55
+ ` #[doc(cfg)] ` is intended to be used alongside [ ` #[cfg(doc)] ` ] [ cfg-doc ] .
68
56
For example, ` #[cfg(any(windows, doc))] ` will preserve the item either on Windows or during the
69
57
documentation process. Then, adding a new attribute ` #[doc(cfg(windows))] ` will tell Rustdoc that
70
58
the item is supposed to be used on Windows. For example:
@@ -81,6 +69,12 @@ pub struct WindowsToken;
81
69
#[cfg(any(unix, doc))]
82
70
#[doc(cfg(unix))]
83
71
pub struct UnixToken ;
72
+
73
+ /// Token struct that is only available with the `serde` feature
74
+ #[cfg(feature = " serde" )]
75
+ #[doc(cfg(feature = " serde" ))]
76
+ #[derive(serde:: Deserialize )]
77
+ pub struct SerdeToken ;
84
78
```
85
79
86
80
In this sample, the tokens will only appear on their respective platforms, but they will both appear
@@ -90,6 +84,7 @@ in documentation.
90
84
` #![feature(doc_cfg)] ` feature gate. For more information, see [ its chapter in the Unstable
91
85
Book] [ unstable-doc-cfg ] and [ its tracking issue] [ issue-doc-cfg ] .
92
86
87
+ [ cfg-doc ] : ./advanced-features.md
93
88
[ unstable-doc-cfg ] : ../unstable-book/language-features/doc-cfg.html
94
89
[ issue-doc-cfg ] : https://github.com/rust-lang/rust/issues/43781
95
90
0 commit comments