Skip to content
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

Merged
merged 7 commits into from
Mar 2, 2021
Merged
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 80 additions & 13 deletions src/doc/rustdoc/src/linking-to-items-by-name.md
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`:

Expand All @@ -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.
Copy link
Member

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.

Copy link
Member Author

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.


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)
Copy link
Member

Choose a reason for hiding this comment

The 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,
Expand All @@ -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].
Expand All @@ -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
Copy link
Member

Choose a reason for hiding this comment

The 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?

Copy link
Member Author

Choose a reason for hiding this comment

The 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)
Expand All @@ -76,19 +96,66 @@ struct Foo {}
fn Foo() {}
```

The following prefixes can be used:
Copy link
Member

Choose a reason for hiding this comment

The 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].
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The 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 master instead? That might have wrong line numbers though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I could change the commit hash to master instead? That might have wrong line numbers though.

Yeah, I think that would be very confusing.

Hmm, I kind of prefer not to tie this down so we can update it in the future.

What do you mean? Documenting it isn't "tying it down".

Copy link
Member

Choose a reason for hiding this comment

The 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