I would like to rename it to `Type::Path`, but then it can't be
re-exported since the name would conflict with the `Path` struct.
Usually enum variants are referred to using their qualified names in
Rust (and parts of rustdoc already do that with `clean::Type`), so this
is also more consistent with the language.
Before, if `register_res` were called on an associated item or enum
variant, it would return the parent's `DefId`. Now, it returns the
actual `DefId`.
This change is a step toward removing `Type::ResolvedPath.did` and
potentially removing `kind_side_channel` in rustdoc. It also just
simplifies rustdoc's behavior.
It is only used in one place; `src` was about a third of `Crate`'s total
size; `Crate` is frequently moved by-value; and `src` can be easily
computed on-demand.
The change to `impl Clean<Path> for hir::TraitRef<'_>` was necessary to
fix a test failure for `src/test/rustdoc/trait-alias-mention.rs`.
Here's why:
The old code path was through `impl Clean<Type> for hir::TraitRef<'_>`,
which called `resolve_type`, which in turn called `register_res`. Now,
because `PolyTrait` uses a `Path` instead of a `Type`, the impl of
`Clean<Path>` was being run, which did not call `register_res`, causing
the trait alias to not be recorded in the `external_paths` cache.
It was only used for sugaring `Fn` trait bounds, and rustdoc already
checks that the `did` is for a `Fn` (or `FnMut`, `FnOnce`) lang item,
so it's not necessary to also check that the `did` belongs to a trait.
The order of the `where` bounds on auto trait impls changed because
rustdoc currently sorts auto trait `where` bounds based on the `Debug`
output for the bound. Now that the bounds have an actual `Res`, they are
being unintentionally sorted by their `DefId` rather than their path.
So, I had to update a test for the change in ordering of the rendered
bounds.
rustdoc: link to stable/beta docs consistently in documentation
This is an alternative to https://github.com/rust-lang/rust/pull/84941 which fixes the problem consistently by linking to stable/beta for *all* items, not just for primitives.
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
cc Mark-Simulacrum - I know [you were dubious about this in the past](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Rustdoc.20unconditionally.20links.20to.20nightly.20libstd.20docs/near/231223124), but I'm not quite sure why? I see this as "just a bugfix", I don't know why rustdoc should unconditionally link to nightly.
cc dtolnay who commented in https://github.com/rust-lang/rust/issues/30693:
> I would welcome a PR to solve this permanently if anyone has ideas for how. I don't believe we need an RFC.
Fixes https://github.com/rust-lang/rust/issues/30693 (note that issue is marked as feature-accepted, although I don't see where it was discussed).
Make match in `register_res` easier to read
- Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs
- Use exhaustive match
- Add comments
This found that register_res is very wrong in at least one way: if it
registers a Res for `Variant`, it should also register one for `Field`.
But I don't know whether the one for Variant should be removed or Field
added. Maybe someone has ideas?
Found while reviewing https://github.com/rust-lang/rust/pull/84176.
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
That PR caused multiple test failures when Rust's channel is changed
from nightly to anything else. The commit will have to be landed again
after the test suite is fixed.
Get rid of fake `DefId`s in rustdoc
Right now there are *many* errors left, but I wanted to show the current state since all that is left to do is fixing the errors.
Resolves#83183
r? `@jyn514`
Currently hex/octal/binary literals with computed values are displayed
like `0_xff_fff_fffu32`, which is invalid since underscores can't be in
the middle of integer prefixes. This properly formats prefixed integers.
- Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs
- Use exhaustive match
- Add comments
This found that register_res is very wrong in at least one way: if it
registers a Res for `Variant`, it should also register one for `Field`.
But I don't know whether the one for Variant should be removed or Field
added. Maybe someone has ideas?
