Unify error reporting for intra-doc links
- Give a suggestion even if there is no span available
- Give a more accurate description of the change than 'use the
disambiguator'
- Write much less code
Closes#75836.
r? @euclio
cc @pickfire - this gets rid of 'disambiguator' like you suggested in https://github.com/rust-lang/rust/pull/75079#discussion_r464464195.
- Give a suggestion even if there is no span available
- Give a more accurate description of the change than 'use the
disambiguator'
- Write much less code
Originally I tried to do a much broader refactoring that got rid of `init_lints` altogether. My reasoning is that now the lints aren't being run anymore (after https://github.com/rust-lang/rust/pull/73566), there's no need to ignore them explicitly. But it seems there are still some lints that aren't affected by setting `lint_mod` to a no-op:
```
deny(pub_use_of_private_extern_crate)
deny(const_err)
warn(unused_imports)
```
(there are possibly more, these are just the ones that failed in the rustdoc test suite).
Some of these seem like we really should be warning about, but that's a much larger change and I don't propose to make it here. So for the time being, this just adds the `unknown_lints` and `renamed_or_removed_lints` passes to the list of lints rustdoc warns about.
- Add a new `prim@` disambiguator, since both modules and primitives are
in the same namespace
- Refactor `report_ambiguity` into a closure
Additionally, I noticed that rustdoc would previously allow
`[struct@char]` if `char` resolved to a primitive (not if it had a
DefId). I fixed that and added a test case.
Fix intra-doc links for associated items
@Manishearth and I found that links of the following sort are broken:
```rust
$ cat str_from.rs
/// [`String::from`]
pub fn foo() {}
$ rustdoc str_from.rs
warning: `[String::from]` cannot be resolved, ignoring it.
--> str_from.rs:4:6
|
4 | /// [`String::from`]
| ^^^^^^^^^^^^^^ cannot be resolved, ignoring
```
It turns out this is because the current implementation only looks at inherent impls (`impl Bar {}`) and traits _for the item being documented_. Note that this is not the same as the item being _linked_ to. So this code would work:
```rust
pub trait T1 {
fn method();
}
pub struct S;
impl T1 for S {
/// [S::method] on method
fn method() {}
}
```
but putting the documentation on `trait T1` would not.
~~I realized that writing it up that my fix is only partially correct: It removes the inherent impls code when it should instead remove the `trait_item` code.~~ Fixed.
Additionally, I discovered while writing this there is some ambiguity: you could have multiple methods with the same name, but for different traits:
```rust
pub trait T1 {
fn method();
}
pub trait T2 {
fn method();
}
/// See [S::method]
pub struct S;
```
Rustdoc should give an ambiguity error here, but since there is currently no way to disambiguate the traits (https://github.com/rust-lang/rust/issues/74563) it does not (https://github.com/rust-lang/rust/pull/74489#issuecomment-673878404).
There is a _third_ ambiguity that pops up: What if the trait is generic and is implemented multiple times with different generic parameters? In this case, my fix does not do very well: it thinks there is only one trait instantiated and links to that trait:
```
/// [`String::from`] -- this resolves to https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.from
pub fn foo() {}
```
However, every `From` implementation has a method called `from`! So the browser picks a random one. This is not the desired behavior, but it's not clear how to avoid it.
To be consistent with the rest of intra-doc links, this only resolves associated items from traits that are in scope. This required changes to rustc_resolve to work cross-crate; the relevant commits are prefixed with `resolve: `. As a bonus, considering only traits in scope is slightly faster. To avoid re-calculating the traits over and over, rustdoc uses a cache to store the traits in scope for a given module.
Doc alias checks: ensure only items appearing in search index can use it
Following the discussion in #73721, I added checks to ensure that only items appearing in the search are allowed to have doc alias.
r? @ollie27
This runs _just_ enough of typeck that later queries don't panic.
Because this is in the same part of the compiler that errors on `impl
Trait`, this special-cases impl Trait for rustdoc and no one else.
Everything is fine.
See comments in the diff; this is such a hack.
The reason this can't be done properly in `register_res` is because
there's no way to get back the parent type: calling
`tcx.parent(assoc_item)` gets you the _impl_, not the type.
You can call `tcx.impl_trait_ref(impl_).self_ty()`, but there's no way
to go from that to a DefId without unwrapping.
These two lints have no relation other than both being nightly-only.
This allows stabilizing intra-doc links without stabilizing
missing_doc_code_examples.
Change the logic such that linking from a public to a private item always
triggers intra_doc_link_resolution_failure. Previously, the warning was
not emitted when --document-private-items is passed.
Also don't rely anymore on the item's visibility, which would falsely trigger
the lint now that the check for --document-private-items is gone.
This commit refactors intra-doc link error reporting to deduplicate code
and decouple error construction from the type of error. This greatly
improves flexibility at each error construction site, while reducing the
complexity of the diagnostic creation.
This commit also rewords the diagnostics for clarity and style:
- Diagnostics should not end in periods.
- It's unnecessary to say "ignoring it". Since this is a warning by
default, it's already clear that the link is ignored.
`evaluate_obligation` can only be run on types that are already valid.
So rustdoc still has to run typeck even though it doesn't care about the
result.
Previously, rustdoc would issue a delay_span_bug ICE on the following code:
```rust
pub fn a() -> impl Fn() -> u32 {
|| content::doesnt::matter()
}
```
This wasn't picked up earlier because having `type Alias = impl Trait;`
in the same module caused _all closures_ to be typechecked, even if they
wouldn't normally. Additionally, if _any_ error was emitted, no
delay_span_bug would be emitted. So as part of this commit all of the
tests were separated out into different files.
Instead, report the error.
This emits the errors on-demand, without special-casing `impl Trait`, so
it should catch all ICEs of this kind, including ones that haven't been
found yet.
Since the error is emitted during type-checking there is less info about
the error; see comments in the code for details.
- Add test case for -> impl Trait
- Add test for impl trait with alias
- Move EmitIgnoredResolutionErrors to rustdoc
This makes `fn typeck_item_bodies` public, which is not desired behavior.
That change should be removed once
https://github.com/rust-lang/rust/pull/74070 is merged.
- Don't visit nested closures twice
