-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Unify behaviours for re-exports of #[doc(hidden)]
#109697
Changes from all commits
9af31ea
ed49e5c
5387d8b
64a4959
cdd5545
918e455
e1b3f41
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,145 @@ | ||
# Re-exports | ||
|
||
Let's start by explaining what are re-exports. To do so, we will use an example where we are | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have time to do this myself but would someone be able to proofread this for grammar? |
||
writing a library (named `lib`) with some types dispatched in sub-modules: | ||
|
||
```rust | ||
pub mod sub_module1 { | ||
pub struct Foo; | ||
} | ||
pub mod sub_module2 { | ||
pub struct AnotherFoo; | ||
} | ||
``` | ||
|
||
Users can import them like this: | ||
|
||
```rust,ignore (inline) | ||
use lib::sub_module1::Foo; | ||
use lib::sub_module2::AnotherFoo; | ||
``` | ||
|
||
But what if you want the types to be available directly at the crate root or if we don't want the | ||
modules to be visible for users? That's where re-exports come in: | ||
|
||
```rust,ignore (inline) | ||
// `sub_module1` and `sub_module2` are not visible outside. | ||
mod sub_module1 { | ||
pub struct Foo; | ||
} | ||
mod sub_module2 { | ||
pub struct AnotherFoo; | ||
} | ||
|
||
// We re-export both types: | ||
pub use crate::sub_module1::Foo; | ||
pub use crate::sub_module2::AnotherFoo; | ||
``` | ||
|
||
And now users will be able to do: | ||
|
||
```rust,ignore (inline) | ||
use lib::{Foo, AnotherFoo}; | ||
``` | ||
|
||
And since both `sub_module1` and `sub_module2` are private, users won't be able to import them. | ||
|
||
Now what's interesting is that the generated documentation for this crate will show both `Foo` and | ||
`AnotherFoo` directly at the crate root, meaning they have been inlined. There are a few rules to | ||
know whether or not a re-exported item will be inlined. | ||
|
||
## Inlining rules | ||
|
||
If a public item comes from a private module, it will be inlined: | ||
|
||
```rust,ignore (inline) | ||
mod private_module { | ||
pub struct Public; | ||
} | ||
|
||
pub mod public_mod { | ||
// `Public` will inlined here since `private_module` is private. | ||
pub use super::private_module::Public; | ||
} | ||
|
||
// `Public` will not be inlined here since `public_mod` is public. | ||
pub use self::public_mod::Public; | ||
``` | ||
|
||
Likewise, if an item has `#[doc(hidden)]` or inherits it (from any of its parents), it | ||
will be inlined: | ||
|
||
```rust,ignore (inline) | ||
#[doc(hidden)] | ||
pub mod public_mod { | ||
pub struct Public; | ||
} | ||
|
||
#[doc(hidden)] | ||
pub struct Hidden; | ||
|
||
// `Public` be inlined since its parent (`public_mod`) has `#[doc(hidden)]`. | ||
pub use self::public_mod::Public; | ||
// `Hidden` be inlined since it has `#[doc(hidden)]`. | ||
pub use self::Hidden; | ||
``` | ||
|
||
The inlining rules are a bit different for glob re-exports (`pub use x::*`) for `#[doc(hidden)]` | ||
types. If we take the previous example and then re-export like this: | ||
|
||
```rust,ignore (inline) | ||
pub use self::*; // It will not inline the `Hidden` struct. | ||
pub use self::public_mod::*; // It will inline the `Public` struct. | ||
``` | ||
|
||
It only impacts elements that have the `#[doc(hidden)]` attributes. If it only inherits it, then it | ||
is inlined. | ||
notriddle marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Inlining with `#[doc(inline)]` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should also explain no_inline in this file |
||
|
||
You can use the `#[doc(inline)]` attribute if you want to force an item to be inlined: | ||
|
||
```rust,ignore (inline) | ||
pub mod public_mod { | ||
pub struct Public; | ||
} | ||
|
||
#[doc(inline)] | ||
pub use self::public_mod::Public; | ||
``` | ||
|
||
With this code, even though `public_mod::Public` is public and present in the documentation, the | ||
`Public` type will be present both at the crate root and in the `public_mod` module. | ||
|
||
## Preventing inlining with `#[doc(no_inline)]` | ||
|
||
On the opposite of the `#[doc(inline)]` attribute, if you want to prevent an item from being | ||
inlined, you can use `#[doc(no_inline)]`: | ||
|
||
```rust,ignore (inline) | ||
pub mod public_mod { | ||
pub struct Public; | ||
} | ||
|
||
#[doc(no_inline)] | ||
pub use self::public_mod::Public; | ||
``` | ||
|
||
In the generated documentation, you will see a re-export at the crate root and not the type | ||
directly. | ||
|
||
## Attributes | ||
|
||
When an item is inlined, its doc comments and most of its attributes will be inlined along with it: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this section is hard to understand. It talks about whether "attributes are inlined" but it's more about attributes whose effects are inlined, or if they are themselves effecting inlining. @notriddle do you have any ideas on how to better frame this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The The docs for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just think that the table below is heterogenous, with the "inlined?" column not quite making sense in a consistent way across entries. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I replaced "Inlined?" with "Is it inlined alongside its item?". |
||
|
||
| Attribute | Is it inlined alongside its item? | Notes | ||
|--|--|-- | ||
| `#[doc=""]` | Yes | Intra-doc links are resolved relative to where the doc comment is defined (`///` is syntax sugar for doc string attributes). | ||
| `#[doc(cfg(..))]` | Yes | | ||
| `#[deprecated]` | Yes | Intra-doc links are resolved relative to where the description is defined. | ||
| `#[doc(alias="")]` | No | | ||
| `#[doc(inline)]` | No | | ||
| `#[doc(no_inline)]` | No | | ||
| `#[doc(hidden)]` | Glob imports | For name-based imports (such as `use module::Item as ModuleItem`), hiding an item acts the same as making it private. For glob-based imports (such as `use module::*`), hidden items are not inlined. | ||
|
||
All other attributes are inherited when inlined, so that the documentation matches the behavior if the inlined item was directly defined at the spot where it's shown. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we shoudl link to this page in the docs for inline/no_inline