| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
TaKO8Ki:suggest-extern-crate-when-failing-to-resolve-use-crate, r=estebank
Suggest `extern crate foo` when failing to resolve `use foo`
closes #97095
r? ``@estebank``
|
|
fix ci error
|
|
|
|
rustdoc: Resolve doc links on fields during early resolution
Another subset of https://github.com/rust-lang/rust/pull/94857 which fixes https://github.com/rust-lang/rust/issues/96429.
This case regressed in https://github.com/rust-lang/rust/pull/96135 when `may_have_doc_links`-based filtering was introduced.
Before that filtering structs could collect traits in scope for their fields, but after the filtering structs won't collect anything if they don't have doc comments on them, so we have to visit fields too.
|
|
This way links referring to `macro_rules` items are resolved correctly
|
|
|
|
its attributes
This should be cheap on rustc side, but it's significant optimization for rustdoc that won't need to decode and process attributes unnecessarily
|
|
|
|
|
|
|
|
|
|
Similar to #86451
CC #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`.
|
|
This allows simplifying a lot of code. It also fixes a subtle bug,
exemplified by the test output changes.
|
|
This currently calls `std` a "crate" in one part of the message and a
"module" in another part. The next commits fix this so it says "crate"
in both places.
|
|
Fixes #90703
|
|
Now that compiletest denies warnings in these tests, they need fixing!
|
|
This helps with (but does not fix)
https://github.com/rust-lang/rust/issues/84738. I tested on
https://github.com/jyn514/objr/commit/edcee7b8124abf0e4c63873e8422ff81beb11ebb
and still hit ICEs.
|
|
|
|
- Fix broken handling of primitive associated items
- Remove fragment hack
Fixes 83083
- more logging
- Update CrateNum hacks
The CrateNum has no relation to where in the dependency tree the crate
is, only when it's loaded. Explicitly special-case core instead of
assuming it will be the first DefId.
- Update and add tests
- Cache calculation of primitive locations
This could possibly be avoided by passing a Cache into
collect_intra_doc_links; but that's a much larger change, and doesn't
seem valuable other than for this.
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
|
|
|
|
## 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
|
|
When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.
|
|
|
|
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.
|
|
|
|
|
|
|
|
rustdoc: Use DiagnosticInfo in more parts of intra-doc links
This makes the code a lot less verbose.
This is separated into lots of tiny commits because it was easier for me that way, but the overall diff isn't that big if you want to read it at once.
r? `@bugadani`
|
|
rustdoc: Cleanup handling of associated items for intra-doc links
Helps with https://github.com/rust-lang/rust/issues/83761 (right now the uses of the resolver are all intermingled with uses of the tyctxt). Best reviewed one commit at a time.
r? ```@bugadani``` maybe? Feel free to reassign :)
|
|
This gets rid of a lot of parameters, as well as fixing a diagnostic
bug.
|
|
Previously, the types looked like this:
- None means this is not an associated item (but may be a variant field)
- Some(Err) means this is known to be an error. I think the only way that can happen is if it resolved and but you had your own anchor.
- Some(Ok(_, None)) was impossible.
Now, this returns a nested Option and does the error handling and
fiddling with the side channel in the caller. As a side-effect, it also
removes duplicate error handling.
This has one small change in behavior, which is that
`resolve_primitive_associated_item` now goes through `variant_field` if
it fails to resolve something. This is not ideal, but since it will be
quickly rejected anyway, I think the performance hit is worth the
cleanup.
This also fixes a bug where struct fields would forget to set the side
channel, adds a test for the bug, and ignores `private_intra_doc_links`
in rustc_resolve (since it's always documented with
--document-private-items).
|
|
This prevents us from warning on links such as `<hello@example.com>`.
Note that we still warn on links such as `<hello@localhost>` because
they have no dots in them. However, the links will still work, even
though a warning is reported.
|
|
|
|
And, now that we do that, we can remove the explanatory note since the
error span should make it clear what the disambiguator is.
|
|
|
|
|
|
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links`
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests
Otherwise, all `rustdoc::` lints would be ignored.
- Register all existing lints as removed
This unfortunately doesn't work with `register_renamed` because tool
lints have not yet been registered when rustc is running. For similar
reasons, `check_backwards_compat` doesn't work either. Call
`register_removed` directly instead.
- Fix fallout
+ Rustdoc lints for compiler/
+ Rustdoc lints for library/
Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for
`rustdoc::intra_doc_link_resolution_failure`, since there was no time
when the latter was valid.
|
|
It should be never break another crate to re-export a public item.
Note that this doesn't check the feature gate at
*all* for other crates:
- Feature-gates aren't currently serialized, so the only way to check
the gate is with ad-hoc attribute checking.
- Checking the feature gate twice (once when documenting the original
crate and one when documenting the current crate) seems not great.
This should still catch using the feature most of the time though, since
people tend to document their own crates.
|
|
The issue was that the `kind, id` override was previously only being
considered for the disambiguator check, not the privacy check. This uses
the same ID for both.
|
|
- Only feature gate associated items
- Add docs to unstable book
|
|
Don't panic when an external crate can't be resolved
This isn't actually a bug, it can occur when rustdoc tries to resolve a
crate that isn't used in the main code.
Fixes #72381.
r? `@kinnison` if you have time, otherwise `@Manishearth`
|
|
|
