-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Update intra-doc link documentation to match the implementation #80874
Changes from 5 commits
0271791
d5392d1
db0b416
21717f0
44c72f6
86e2fcb
c2694f1
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 |
---|---|---|
@@ -1,7 +1,7 @@ | ||
# Linking to items by name | ||
|
||
Rustdoc is capable of directly linking to other rustdoc pages using the path of | ||
the item as a link. | ||
the item as a link. This is referred to as an 'intra-doc link'. | ||
|
||
For example, in the following code all of the links will link to the rustdoc page for `Bar`: | ||
|
||
|
@@ -24,11 +24,29 @@ pub struct Foo4; | |
pub struct Bar; | ||
``` | ||
|
||
Unlike normal Markdown, `[bar][Bar]` syntax is also supported without needing a | ||
`[Bar]: ...` reference link, and links are case-sensitive. | ||
|
||
Backticks around the link will be stripped, so ``[`Option`]`` will correctly | ||
link to `Option`. | ||
|
||
You can refer to anything in scope, and use paths, including `Self`, `self`, | ||
`super`, and `crate`. You may also use `foo()` and `foo!()` to refer to methods/functions and macros, respectively. | ||
## Valid links | ||
|
||
You can refer to anything in scope, and use paths, including `Self`, `self`, `super`, and | ||
`crate`. Associated items (functions, types, and constants) are supported, but [not for blanket | ||
trait implementations][#79682]. Rustdoc also supports linking to the following primitives, which | ||
have no path and cannot be imported: | ||
|
||
- [`slice`](../std/primitive.slice.html) | ||
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'd collapse this into a single sentence. Most people don't need to care about this. |
||
- [`array`](../std/primitive.array.html) | ||
- [`tuple`](../std/primitive.tuple.html) | ||
- [`unit`](../std/primitive.unit.html) | ||
- [`fn`](../std/primitive.fn.html) | ||
- [`pointer`](../std/primitive.pointer.html), `*`, `*const`, or `*mut` | ||
- [`reference`](../std/primitive.reference.html), `&`, or `&mut` | ||
- [`never`](../std/primitive.never.html) or `!` | ||
|
||
camelid marked this conversation as resolved.
Show resolved
Hide resolved
|
||
[#79682]: https://github.com/rust-lang/rust/pull/79682 | ||
|
||
You can also refer to items with generic parameters like `Vec<T>`. The link will | ||
resolve as if you had written ``[`Vec<T>`](Vec)``. Fully-qualified syntax (for example, | ||
|
@@ -53,7 +71,7 @@ impl<T> AsyncReceiver<T> { | |
} | ||
``` | ||
|
||
You can also link to sections using URL fragment specifiers: | ||
Rustdoc allows using URL fragment specifiers, just like a normal link: | ||
|
||
```rust | ||
/// This is a special implementation of [positional parameters]. | ||
|
@@ -62,9 +80,11 @@ You can also link to sections using URL fragment specifiers: | |
struct MySpecialFormatter; | ||
``` | ||
|
||
Paths in Rust have three namespaces: type, value, and macro. Item names must be | ||
unique within their namespace, but can overlap with items outside of their | ||
namespace. In case of ambiguity, rustdoc will warn about the ambiguity and ask you to disambiguate, which can be done by using a prefix like `struct@`, `enum@`, `type@`, `trait@`, `union@`, `const@`, `static@`, `value@`, `fn@`, `function@`, `mod@`, `module@`, `method@`, `prim@`, `primitive@`, `macro@`, or `derive@`: | ||
## Namespaces and Disambiguators | ||
|
||
Paths in Rust have three namespaces: type, value, and macro. Item names must be unique within | ||
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. It may not be necessary, but do you want to note that the type namespace includes modules? 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 would prefer not to; if you get it wrong it will be clear from the error message. If we mention modules we should also say functions are in the value namespace, though. |
||
their namespace, but can overlap with items in other namespaces. In case of ambiguity, | ||
rustdoc will warn about the ambiguity and ask you to disambiguate. | ||
|
||
```rust | ||
/// See also: [`Foo`](struct@Foo) | ||
|
@@ -76,19 +96,66 @@ struct Foo {} | |
fn Foo() {} | ||
``` | ||
|
||
The following prefixes can be used: | ||
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'd collapse this into a single sentence. Most people don't need to care about this, and rustdoc helps with diagnostics when they do. |
||
|
||
- `struct@` | ||
- `enum@` | ||
- `type@` | ||
- `trait@` | ||
- `union@` | ||
- `const@` | ||
- `static@` | ||
- `value@` | ||
- `fn@` / `function@` / `method@` | ||
- `mod@` / `module@` | ||
- `prim@` / `primitive@` | ||
- `macro@` | ||
- `derive@` | ||
|
||
These prefixes will be stripped when displayed in the documentation, so `[struct@Foo]` | ||
will be rendered as `Foo`. | ||
|
||
You can also disambiguate for functions by adding `()` after the function name, | ||
or for macros by adding `!` after the macro name: | ||
|
||
```rust | ||
/// See also: [`Foo`](struct@Foo) | ||
struct Bar; | ||
/// This is different from [`foo!`] | ||
fn foo() {} | ||
|
||
/// This is different from [`Foo()`] | ||
struct Foo {} | ||
/// This is different from [`foo()`] | ||
macro_rules! foo { | ||
() => {} | ||
} | ||
``` | ||
|
||
fn Foo() {} | ||
## Warnings, re-exports, and scoping | ||
|
||
Links are resolved in the scope of the module where the item is defined, even | ||
when the item is re-exported. If a link from another crate fails to resolve, no | ||
warning is given. | ||
|
||
When re-exporting an item, rustdoc allows adding additional documentation to it. | ||
That additional documentation will be resolved in the scope of the re-export, not | ||
the original, allowing you to link to items in the new crate. The new links | ||
will still give a warning if they fail to resolve. | ||
|
||
```rust | ||
/// See also [foo()] | ||
pub use std::process::Command; | ||
|
||
pub fn foo() {} | ||
``` | ||
|
||
Note: Because of how `macro_rules!` macros are scoped in Rust, the intra-doc links of a `macro_rules!` macro will be resolved [relative to the crate root][#72243], as opposed to the module it is defined in. | ||
This is especially useful for proc-macros, which must always be defined in their own dedicated crate. | ||
|
||
Note: Because of how `macro_rules!` macros are scoped in Rust, the intra-doc links of a | ||
`macro_rules!` macro will be resolved [relative to the crate root][#72243], as opposed to the | ||
module it is defined in. | ||
|
||
If links do not look 'sufficiently like' an intra-doc link, they will be ignored and no warning | ||
will be given, even if the link fails to resolve. For example, any link containing `/` or `[]` | ||
characters will be ignored. You can see the full criteria for 'sufficiently like' in [the source | ||
code]. | ||
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'm not sure if it's a good idea to link to the source code here. For one, it will very easily become out-of-date because it's tied to a particular commit. I think we should either skip this or include the list directly in the documentation. 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. Hmm, I kind of prefer not to tie this down so we can update it in the future. Maybe I could change the commit hash to 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.
Yeah, I think that would be very confusing.
What do you mean? Documenting it isn't "tying it down". 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. So, this is a not a reference, this is a book, and I don't think it should go into that much detail. We do not need to document every last corner of the implementation here. Let's just drop this section. |
||
|
||
[#72243]: https://github.com/rust-lang/rust/issues/72243 | ||
[the source code]: https://github.com/rust-lang/rust/blob/34628e5b533d35840b61c5db0665cf7633ed3c5a/src/librustdoc/passes/collect_intra_doc_links.rs#L982 |
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 should probably note somewhere that non-intra-doc links are case-insensitive; see #80882.
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.
Ugh, #80882 is a mess. I think I'd prefer to see what the plan is there before updating the documentation.