Fix intra-doc links on pub re-exports
Partial fix for https://github.com/rust-lang/rust/issues/76073 - This removes the incorrect error, but doesn't show the documentation anywhere.
r? @GuillaumeGomez
Remove disambiguators from intra doc link text
Closes https://github.com/rust-lang/rust/issues/65354.
r? @Manishearth
The commits are mostly atomic, but there might be some mix between them here and there. I recommend reading 'refactor ItemLink' and 'refactor RenderedLink' on their own though, lots of churn without any logic changes.
- Preserve suffixes when displaying
- Rename test file to match `intra-link*`
- Remove unnecessary .clone()s
- Improve comments and naming
- Fix more bugs and add tests
- Escape intra-doc link example in public documentation
rustdoc: do not use plain summary for trait impls
Fixes#38386.
Fixes#48332.
Fixes#49430.
Fixes#62741.
Fixes#73474.
Unfortunately this is not quite ready to go because the newly-working links trigger a bunch of linkcheck failures. The failures are tough to fix because the links are resolved relative to the implementor, which could be anywhere in the module hierarchy.
(In the current docs, these links end up rendering as uninterpreted markdown syntax, so I don't think these failures are any worse than the status quo. It might be acceptable to just add them to the linkchecker whitelist.)
Ideally this could be fixed with intra-doc links ~~but it isn't working for me: I am currently investigating if it's possible to solve it this way.~~ Opened #73829.
EDIT: This is now ready!
Related to https://github.com/rust-lang/rust/issues/65354
- Pass through the replacement text to `markdown.rs`
- Add some tests
- Add a state machine that actually replaces the text when parsing Markdown
Fira Sans is what's used for module lists and other item lists.
Previously, the default body font, "Source Serif Pro", was used for
crate lists, which didn't visually match other item lists.
Fix intra-doc links for cross-crate re-exports of default trait methods
The original fix for this was very simple: https://github.com/rust-lang/rust/pull/58972 ignored `extern_traits` because before https://github.com/rust-lang/rust/issues/65983 was fixed, they would always fail to resolve, giving spurious warnings. So the first commit just undoes that change, so extern traits are now seen by the `collect_intra_doc_links` pass. There are also some minor changes in `librustdoc/fold.rs` to avoid borrowing the `extern_traits` RefCell more than once at a time.
However, that brought up a much more thorny problem. `rustc_resolve` started giving 'error: cannot find a built-in macro with name `cfg`' when documenting `libproc_macro` (I still haven't been able to reproduce on anything smaller than the full standard library). The chain of events looked like this (thanks @eddyb for the help debugging!):
0. `x.py build --stage 1` builds the standard library and creates a sysroot
1. `cargo doc` does something like `cargo check` to create `rmeta`s for all the crates (unrelated to what was built above)
2. the `cargo check`-like `libcore-*.rmeta` is loaded as a transitive dependency *and claims ownership* of builtin macros
3. `rustdoc` later tries to resolve some path in a doc link
4. suggestion logic fires and loads "extern prelude" crates by name
5. the sysroot `libcore-*.rlib` is loaded and *fails to claim ownership* of builtin macros
`rustc_resolve` gives the error after step 5. However, `rustdoc` doesn't need suggestions at all - `resolve_str_path_error` completely discards the `ResolutionError`! The fix implemented in this PR is to skip the suggestion logic for `resolve_ast_path`: pass `record_used: false` and skip `lookup_import_candidates` when `record_used` isn't set.
It's possible that if/when https://github.com/rust-lang/rust/issues/74207 is implemented this will need a more in-depth fix which returns a `ResolutionError` from `compile_macro`, to allow rustdoc to reuse the suggestions from rustc_resolve. However, that's a much larger change and there's no need for it yet, so I haven't implemented it here.
Fixes https://github.com/rust-lang/rust/issues/73829.
r? @GuillaumeGomez
Fix intra-doc links for associated constants
Previously, only associated functions would be resolved. Fixes the issues in https://github.com/rust-lang/rust/pull/75969#discussion_r477898003.
I'm a little uncomfortable hard-coding the string constants, but it looks like that's how it's done elsewhere. I might make a follow-up PR at some point putting it in one place.
Not sure how to test associated types, since AFAIK there aren't any on primitives.
r? @Manishearth
#58972 ignored extern_traits because before #65983 was fixed, they
would always fail to resolve, giving spurious warnings.
This undoes that change, so extern traits are now seen by the
`collect_intra_doc_links` pass. There are also some minor changes in
librustdoc/fold.rs to avoid borrowing the extern_traits RefCell more
than once at a time.
rustc_lexer is the lossless lexer, which is a better fit for
approximate syntax highlighting.
As a side-effect, we can now syntax-highlight even broken code.
Previously, associated items would only be available for linking
directly on the `impl Trait for Type`. Now they can be used anywhere.
- Make `item` for resolve mandatory
- Refactor resolving associated items into a separate function
- Remove broken trait_item logic
- Don't skip the type namespace for associated items
- Only call `variant_field` for `TypeNS`
- Add test for associated items
- Use exhaustive matches instead of wildcards
Wildcards caused several bugs while implementing this.
Handle projection predicates in the param env for auto-trait docs
Fixes#72213
Any predicates in the param env are guaranteed to hold, so we don't need
to do any additional processing of them if we come across them as
sub-obligations of a different predicate. This allows us to avoid adding
the same predicate to the computed ParamEnv multiple times (but with
different regions each time), which causes an ambiguity error during
fulfillment.
Display elided lifetime for non-reference type in doc
In edition 2018 we encourage writing `<'_>` explicitly, so rustdoc should display like such as well.
Fixes#75225
~~Somehow when I run the compiled rustdoc using `cargo +stage2 doc` on other crates, it correctly produces `<'_>`, but I couldn't get the std doc to do the same with `./x.py doc --stage 2`. Might this be related to the recent change to x.py about how the doc is built?~~
Fixes#72213
Any predicates in the param env are guaranteed to hold, so we don't need
to do any additional processing of them if we come across them as
sub-obligations of a different predicate. This allows us to avoid adding
the same predicate to the computed ParamEnv multiple times (but with
different regions each time), which causes an ambiguity error during
fulfillment.
This caused the following false positive:
```
warning: unresolved link to `Default::default`
--> /home/joshua/rustc2/default.rs:1:14
|
1 | /// Link to [Default::default()]
| ^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(broken_intra_doc_links)]` on by default
note: this item resolved to a trait, which did not match the disambiguator 'fn'
--> /home/joshua/rustc2/default.rs:1:14
|
1 | /// Link to [Default::default()]
| ^^^^^^^^^^^^^^^^^^
```
