1 # The `#[doc]` attribute
3 The `#[doc]` attribute lets you control various aspects of how `rustdoc` does
6 The most basic function of `#[doc]` is to handle the actual documentation
7 text. That is, `///` is syntax sugar for `#[doc]`. This means that these two
11 /// This is a doc comment.
12 #[doc = " This is a doc comment."]
15 (Note the leading space in the attribute version.)
17 In most cases, `///` is easier to use than `#[doc]`. One case where the latter is easier is
18 when generating documentation in macros; the `collapse-docs` pass will combine multiple
19 `#[doc]` attributes into a single doc comment, letting you generate code like this:
24 #[doc = "doc comment"]
27 Which can feel more flexible. Note that this would generate this:
30 #[doc = "This is\n a \ndoc comment"]
33 but given that docs are rendered via Markdown, it will remove these newlines.
35 The `doc` attribute has more options though! These don't involve the text of
36 the output, but instead, various aspects of the presentation of the output.
37 We've split them into two kinds below: attributes that are useful at the
38 crate level, and ones that are useful at the item level.
42 These options control how the docs look at a macro level.
44 ### `html_favicon_url`
46 This form of the `doc` attribute lets you control the favicon of your docs.
49 #![doc(html_favicon_url = "https://example.com/favicon.ico")]
52 This will put `<link rel="shortcut icon" href="{}">` into your docs, where
53 the string for the attribute goes into the `{}`.
55 If you don't use this attribute, there will be no favicon.
59 This form of the `doc` attribute lets you control the logo in the upper
60 left hand side of the docs.
63 #![doc(html_logo_url = "https://example.com/logo.jpg")]
66 This will put `<a href='index.html'><img src='{}' alt='logo' width='100'></a>` into
67 your docs, where the string for the attribute goes into the `{}`.
69 If you don't use this attribute, there will be no logo.
71 ### `html_playground_url`
73 This form of the `doc` attribute lets you control where the "run" buttons
74 on your documentation examples make requests to.
77 #![doc(html_playground_url = "https://playground.example.com/")]
80 Now, when you press "run", the button will make a request to this domain.
82 If you don't use this attribute, there will be no run buttons.
84 ### `issue_tracker_base_url`
86 This form of the `doc` attribute is mostly only useful for the standard library;
87 When a feature is unstable, an issue number for tracking the feature must be
88 given. `rustdoc` uses this number, plus the base URL given here, to link to
92 #![doc(issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/")]
97 The `#[doc(html_root_url = "…")]` attribute value indicates the URL for
98 generating links to external crates. When rustdoc needs to generate a link to
99 an item in an external crate, it will first check if the extern crate has been
100 documented locally on-disk, and if so link directly to it. Failing that, it
101 will use the URL given by the `--extern-html-root-url` command-line flag if
102 available. If that is not available, then it will use the `html_root_url`
103 value in the extern crate if it is available. If that is not available, then
104 the extern items will not be linked.
107 #![doc(html_root_url = "https://docs.rs/serde/1.0")]
112 By default, `rustdoc` will include the source code of your program, with links
113 to it in the docs. But if you include this:
116 #![doc(html_no_source)]
121 ### `test(no_crate_inject)`
123 By default, `rustdoc` will automatically add a line with `extern crate my_crate;` into each doctest.
124 But if you include this:
127 #![doc(test(no_crate_inject))]
132 ### `test(attr(...))`
134 This form of the `doc` attribute allows you to add arbitrary attributes to all your doctests. For
135 example, if you want your doctests to fail if they produce any warnings, you could add this:
138 #![doc(test(attr(deny(warnings))))]
143 These forms of the `#[doc]` attribute are used on individual items, to control how
146 ## `#[doc(no_inline)]`/`#[doc(inline)]`
148 These attributes are used on `use` statements, and control where the documentation shows
149 up. For example, consider this Rust code:
161 The documentation will generate a "Re-exports" section, and say `pub use bar::Bar;`, where
162 `Bar` is a link to its page.
164 If we change the `use` line like this:
171 Instead, `Bar` will appear in a `Structs` section, just like `Bar` was defined at the
172 top level, rather than `pub use`'d.
174 Let's change our original example, by making `bar` private:
186 Here, because `bar` is not public, `Bar` wouldn't have its own page, so there's nowhere
187 to link to. `rustdoc` will inline these definitions, and so we end up in the same case
188 as the `#[doc(inline)]` above; `Bar` is in a `Structs` section, as if it were defined at
189 the top level. If we add the `no_inline` form of the attribute:
202 Now we'll have a `Re-exports` line, and `Bar` will not link to anywhere.
204 One special case: In Rust 2018 and later, if you `pub use` one of your dependencies, `rustdoc` will
205 not eagerly inline it as a module unless you add `#[doc(inline)]`.
209 Any item annotated with `#[doc(hidden)]` will not appear in the documentation, unless
210 the `strip-hidden` pass is removed.
212 ## `#[doc(primitive)]`
214 Since primitive types are defined in the compiler, there's no place to attach documentation
215 attributes. This attribute is used by the standard library to provide a way to generate
216 documentation for primitive types.
218 ## `#[cfg(rustdoc)]`: Documenting platform-/feature-specific information
220 For conditional compilation, Rustdoc treats your crate the same way the compiler does: Only things
221 from the host target are available (or from the given `--target` if present), and everything else is
222 "filtered out" from the crate. This can cause problems if your crate is providing different things
223 on different targets and you want your documentation to reflect all the available items you
226 If you want to make sure an item is seen by Rustdoc regardless of what platform it's targeting,
227 you can apply `#[cfg(rustdoc)]` to it. Rustdoc sets this whenever it's building documentation, so
228 anything that uses that flag will make it into documentation it generates. To apply this to an item
229 with other `#[cfg]` filters on it, you can write something like `#[cfg(any(windows, rustdoc))]`.
230 This will preserve the item either when built normally on Windows, or when being documented
233 Please note that this feature won't be passed when building doctests.
238 /// Token struct that can only be used on Windows.
239 #[cfg(any(windows, rustdoc))]
240 pub struct WindowsToken;
241 /// Token struct that can only be used on Unix.
242 #[cfg(any(unix, rustdoc))]
243 pub struct UnixToken;
246 Here, the respective tokens can only be used by dependent crates on their respective platforms, but
247 they will both appear in documentation.