| Age | Commit message (Collapse) | Author | Lines |
|---|
|
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix async-std by special-casing rustdoc in typeck
https://github.com/rust-lang/rust/issues/75100
|
|
|
|
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.
|
|
Use outermost invocation span for doctest names
Fixes #70090.
This PR also allows using aux-build files in rustdoc-ui tests.
|
|
|
|
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.
|
|
|
|
Clearly it has been resolved, because we say on the next line what it
resolved to.
|
|
|
|
|
|
- Don't mark impl trait as an error
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These two lints have no relation other than both being nightly-only.
This allows stabilizing intra-doc links without stabilizing
missing_doc_code_examples.
|
|
The additional note helps explaining why the lint was triggered and that
--document-private-items directly influences the link resolution.
|
|
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.
|
|
intra_doc_resolution_failure is not a lint.
|
|
Move #[doc(alias)] check in rustc
Part of #73721.
r? @ollie27
|
|
This matches the previous behavior of everybody_loops and is also more
consistent than special-casing impls.
|
|
`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
|
|
- Remove unnecessary `should_loop` variable
- Report errors for trait implementations
These should give resolution errors because they are visible outside the
current scope. Without these errors, rustdoc will give ICEs:
```
thread 'rustc' panicked at 'attempted .def_id() on invalid res: Err', /home/joshua/src/rust/src/libstd/macros.rs:16:9
15: rustc_hir::def::Res<Id>::def_id
at /home/joshua/src/rust/src/librustc_hir/def.rs:382
16: rustdoc::clean::utils::register_res
at src/librustdoc/clean/utils.rs:627
17: rustdoc::clean::utils::resolve_type
at src/librustdoc/clean/utils.rs:587
```
- Add much more extensive tests
+ fn -> impl -> fn
+ fn -> impl -> fn -> macro
+ errors in function parameters
+ errors in trait bounds
+ errors in the type implementing the trait
+ unknown bounds for the type
+ unknown types in function bodies
+ errors generated by macros
- Use explicit state instead of trying to reconstruct it from random info
- Use an enum instead of a boolean
- Add example of ignored error
|
|
rustdoc: Allow linking from private items to private types
Fixes #74134
After PR #72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.
Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
|
|
|
|
|
|
As per the discussion in PR #74147, the 4 individual tests are replaced by a
single one.
The test is expanded to cover all 4 public/private cases, each with and without
--document-private-items.
|
|
|
