| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=notriddle
Fix panic when handling intra doc links generated from macro
Fixes #78591.
Fixes #92789.
r? ``@notriddle``
|
|
|
|
|
|
|
|
|
|
r=GuillaumeGomez
rustdoc: resolve intra-doc links when checking HTML
Similar to #86451
CC #67799
Given this test case:
```rust
#![warn(rustdoc::invalid_html_tags)]
#![warn(rustdoc::broken_intra_doc_links)]
pub struct ExistentStruct<T>(T);
/// This [test][ExistentStruct<i32>] thing!
pub struct NoError;
```
This pull request silences the following, spurious warning:
```text
warning: unclosed HTML tag `i32`
--> test.rs:6:31
|
6 | /// This [test][ExistentStruct<i32>] thing!
| ^^^^^
|
note: the lint level is defined here
--> test.rs:1:9
|
1 | #![warn(rustdoc::invalid_html_tags)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: try marking as source code
|
6 | /// This [test][`ExistentStruct<i32>`] thing!
| + +
warning: 1 warning emitted
```
|
|
|
|
|
|
Similar to #86451
CC #67799
|
|
rustdoc: Special-case macro lookups less
Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`
Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
struct S;
macro_rules! mac { () => {} }
// `mac`'s scope starts here
/// `mac` <- `resolve_str_path_error` won't see this
struct Z;
//`mac`'s scope ends here
}
```
This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.
This is a smaller version of https://github.com/rust-lang/rust/pull/91427.
r? `@petrochenkov`
|
|
r=CraftSpider
rustdoc: correct unclosed HTML tags as generics
CC https://github.com/rust-lang/rust/issues/67799
|
|
Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`
Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
struct S;
macro_rules! mac { () => {} }
// `mac`'s scope starts here
/// `mac` <- `resolve_str_path_error` won't see this
struct Z;
//`mac`'s scope ends here
}
```
This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.
This also adds a failing test case which will catch trying to remove `all_macros`.
|
|
|
|
Another one of those "good grief, I just submitted it and NOW I think of it" moments.
|
|
|
|
|
|
|
|
rustdoc: Remove `def_id_no_primitives`
Fixes #90187.
|
|
Fixes #93428
This fix is a response to a couple of special cases related to the
`module_id`, which is eventually used for trait candidates:
* The module id is always set to the current crate, when checking `crate::`.
Normally, the set of in-scope traits would be set in `load_links_in_attrs`,
but if there are no doc comments, then that loop will never run.
* the module id is set to the parent module, when resolving a module
that is spelled like this:
// Notice how we use an outlined doc comment here!
// [`Test::my_fn`]
mod something {
}
As with the above problem with `crate::`, we need to make sure the
module gets its traits in scope resolved, even if it has no doc comments
of its own.
|
|
rustdoc: Pre-calculate traits that are in scope for doc links
This eliminates one more late use of resolver (part of #83761).
At early doc link resolution time we go through parent modules of items from the current crate, reexports of items from other crates, trait items, and impl items collected by `collect-intra-doc-links` pass, determine traits that are in scope in each such module, and put those traits into a map used by later rustdoc passes.
r? `@jyn514`
|
|
Store a `Symbol` instead of an `Ident` in `AssocItem`
This is the same idea as #92533, but for `AssocItem` instead
of `VariantDef`/`FieldDef`.
With this change, we no longer have any uses of
`#[stable_hasher(project(...))]`
|
|
This eliminates one more late use of resolver
|
|
They don't need to be `pub`. Making them crate-private improves code
clarity and `dead_code` linting.
|
|
This is the same idea as #92533, but for `AssocItem` instead
of `VariantDef`/`FieldDef`.
With this change, we no longer have any uses of
`#[stable_hasher(project(...))]`
|
|
Before, the trait's associated item would be used. Now, the impl's
associated item is used. The only exception is for impls that use
default values for associated items set by the trait. In that case,
the trait's associated item is still used.
As an example of the old and new behavior, take this code:
trait MyTrait {
type AssocTy;
}
impl MyTrait for String {
type AssocTy = u8;
}
Before, when resolving a link to `String::AssocTy`,
`resolve_associated_trait_item` would return the associated item for
`MyTrait::AssocTy`. Now, it would return the associated item for
`<String as MyTrait>::AssocTy`, as it claims in its docs.
|
|
remove the definition of def_id_no_primitives and change;
a missing use was modified;
narrow the Cache accessibility of BadImplStripper;
|
|
|
|
|
|
Remove some unnecessary uses of `FieldDef::ident`
Followup from #92533.
cc ``@Aaron1011`` ``@petrochenkov``
|
|
rustdoc: fix intra-link for generic trait impls
fixes #92662
r? `````@camelid`````
|
|
rustdoc: Yet more intra-doc links cleanup
r? `@Manishearth`
|
|
|
|
Also ignore clippy's "collapsible if..." lints.
|
|
|
|
|
|
The field is also renamed from `ident` to `name. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.
This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.
|
|
|
|
These closures were quite complex and part of a quite complex function.
The fact that they are closures makes mistakes likely when refactoring.
For example, earlier, I meant to use `resolved`, an argument of the
closure, but I instead typed `res`, which captured a local variable and
caused a subtle bug that led to a confusing test failure.
Extracting them as functions makes the code easier to understand and
refactor.
|
|
I'm still not sure why this hack works so seemingly well.
|
|
Now that `res` is used directly, it seems the conditional is
unnecessary.
|
|
This allows simplifying a lot of code. It also fixes a subtle bug,
exemplified by the test output changes.
|
|
This hack was added in 6ab1f05697c3f2df4e439a05ebcee479a9a16d80.
I don't know what change allowed removing the hack, but that commit
added a test (which I presume covered the hack's behavior), and all
tests are passing with this change. So, I think it should be good.
|
|
rustdoc: Remove the intra-doc links side channel
The side channel made the code much more complex and harder to
understand. It was added as a temporary workaround in
0c99d806eabd32a2ee2e6c71b400222b99c659e1, but it's no longer necessary.
The addition of `UrlFragment` in #92088 was the key to getting rid of
the side channel. The semantic information (rather than the strings that
used to be used for fragments) that is now captured by `UrlFragment` is
enough to obviate the side channel. An additional change had to be made
to `UrlFragment` in this PR to make this possible: it now records
`DefId`s rather than item names.
This PR also consolidates the checks for anchor conflicts into one place.
r? `@Manishearth`
|
|
resolution and later passes
|
|
This allows eliminating branches in the code where a user-written
fragment is impossible.
|
|
Hooray! It was no longer used, so it can just be deleted.
|
|
|
|
|
|
I had the epiphany that now that fragments are "semantic" -- rather than
just strings -- they fill the role that used to be handled by the side
channel. I think I may be able to get rid of the other uses of the side
channel using this technique too.
|
|
|
