| Age | Commit message (Collapse) | Author | Lines |
|
Fixes #83046
The program
fn main() {
println!("{:?}", '"');
println!("{:?}", "'");
}
would previously print
'\"'
"\'"
With this patch it now prints:
'"'
"'"
|
|
|
|
rustdoc: allow list syntax for #[doc(alias)] attributes
Fixes https://github.com/rust-lang/rust/issues/81205.
It now allows to have:
```rust
#[doc(alias = "x")]
// and:
#[doc(alias("y", "z"))]
```
cc ``@jplatte``
r? ``@jyn514``
|
|
Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
|
|
Add a `min_type_alias_impl_trait` feature gate
This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types, closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete, as they have various ways to ICE the compiler or cause query cycles where they shouldn't).
r? `@nikomatsakis`
This is best reviewed commit-by-commit
|
|
actual changes in behaviour
This makes `type_alias_impl_trait` not actually do anything anymore
|
|
Find more invalid doc attributes
- Lint on `#[doc(123)]`, `#[doc("hello")]`, etc.
- Lint every attribute; e.g., will now report two warnings for `#[doc(foo, bar)]`
- Add hyphen to "crate level"
- Display paths like `#[doc(foo::bar)]` correctly instead of as an empty string
|
|
- Tweak lint message
- Display multi-segment paths correctly
|
|
Rename `rustdoc` to `rustdoc::all`
When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like
```
warning: unknown lint: `rustdoc`
```
The lint group still worked when rustdoc ran, since rustdoc added the group itself.
This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.
Follow-up to #80527.
r? ``@Manishearth``
|
|
It seems there are two copies of it: one in `src/test/ui/attributes/`
and one in `src/test/rustdoc-ui/`. I'm guessing this is to test that the
lint is emitted both when you run the compiler and when you run rustdoc.
|
|
"crate level attribute" -> "crate-level attribute"
|
|
|
|
Cleanup rustdoc warnings
## Clean up error reporting for deprecated passes
Using `error!` here goes all the way back to the original commit, https://github.com/rust-lang/rust/pull/8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See https://github.com/rust-lang/rust/pull/81932#issuecomment-785291244 for further context.
- Use spans for deprecated attributes
- Use a proper diagnostic for unknown passes, instead of error logging
- Add tests for unknown passes
- Improve some wording in diagnostics
## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!`
This also adds a test for the output.
This was added in https://github.com/rust-lang/rust/pull/52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in https://github.com/rust-lang/rust/pull/50541.
|
|
Warn on `#![doc(test(...))]` on items other than the crate root and use future incompatible lint
Part of #82672.
This PR does multiple things:
* Create a new `INVALID_DOC_ATTRIBUTE` lint which is also "future incompatible", allowing us to use it as a warning for the moment until it turns (eventually) into a hard error.
* Use this link when `#![doc(test(...))]` isn't used at the crate level.
* Make #82702 use this new lint as well.
r? ``@jyn514``
|
|
When rustdoc lints were changed to be tool lints, the `rustdoc` group
was removed, leading to spurious warnings like
```
warning: unknown lint: `rustdoc`
```
The lint group still worked when rustdoc ran, since rustdoc added the group itself.
This renames the group to `rustdoc::all` for consistency with
`clippy::all` and the rest of the rustdoc lints.
|
|
|
|
|
|
|
|
|
|
Make rustdoc lints a tool lint instead of built-in
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently, though).
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests
- Move lint machinery into a separate file
- Add `declare_rustdoc_lint!` macro
Unblocks https://github.com/rust-lang/rust/pull/80300, https://github.com/rust-lang/rust/pull/79816, https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786.
## Current status
This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519)
|
|
This prevents breakage across the ecosystem, since the error was just
introduced recently without first having a warning period.
|
|
This also adds a test for the output and fixes `rustc_attr` to properly
know that `plugins` is a valid attribute.
|
|
- Use spans for deprecated attributes
- Use a proper diagnostic for unknown passes, instead of error logging
- Add tests for unknown passes
- Improve some wording in diagnostics
|
|
|
|
- Move MISSING_CRATE_LEVEL_DOCS to rustdoc directly
- Update documentation
This also takes the opportunity to make the `no-crate-level-doc-lint`
test more specific.
|
|
- Use `register_renamed` when rustdoc is running so the lint will still
be active and use a structured suggestion
- Test the behavior for rustc, not just for rustdoc (because it differs)
|
|
- 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.
|
|
Warn about unknown doc attributes
Fixes #82652.
For the text error, I decided to go for "invalid" instead of "unknown". What do you think?
r? `@jyn514`
|
|
Check stability and feature attributes in rustdoc
Fixes #82588.
cc `@Nemo157` `@camelid`
r? `@jyn514`
|
|
|
|
`src/test/rustdoc-ui/deprecated-attrs.rs`
tells rustdoc to run the `collapse-docs` pass, which no longer exists
(it was removed in https://github.com/rust-lang/rust/pull/80261).
Rustdoc doesn't actually give a proper diagnostic here; instead it
prints an `error!` log. Now that tracing is compiled unconditionally,
the log is now being emitted by default, because it's at the error
level.
rustdoc shouldn't be using `error!` logging for diagnostics in the first
place, but in the meantime this change gets the testsuite to pass.
|
|
|
|
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.
|
|
rustdoc: Support argument files
Factors out the `rustc_driver` logic that handles argument files so that rustdoc supports them as well, e.g.:
rustdoc `@argfile`
This is needed to be able to generate docs for projects that already use argument files when compiling them, e.g. projects that pass a huge number of `--cfg` arguments.
The feature was stabilized for `rustc` in #66172.
|
|
Factors out the `rustc_driver` logic that handles argument files
so that rustdoc supports them as well, e.g.:
rustdoc @argfile
This is needed to be able to generate docs for projects that
already use argument files when compiling them, e.g. projects
that pass a huge number of `--cfg` arguments.
The feature was stabilized for `rustc` in #66172.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
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.
|
|
|
|
The `Deref` cycle checks added as part of #80653 were "unbalanced" in the sense
that the main content code path checks for cycles _before_ descending, while the
sidebar checks _after_. Checking _before_ is correct, so this changes the
sidebar path to match the main content path.
|
|
This option will allow splitting the compile-time from the run-time
directory of doctest invocations and is one step to solve
https://github.com/rust-lang/cargo/issues/8993#issuecomment-760088944
|
|
- Only feature gate associated items
- Add docs to unstable book
|
|
|
|
|
|
Recursively document methods via `Deref` traits
This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level.

Fixes https://github.com/rust-lang/rust/issues/26207
Fixes https://github.com/rust-lang/rust/issues/53038
Fixes https://github.com/rust-lang/rust/issues/71640
r? `@jyn514`
|
|
|
|
Get rid of custom pretty-printing in rustdoc
and use rustc_hir_pretty directly instead.
Closes https://github.com/rust-lang/rust/issues/79497.
r? `@CraftSpider`
|
|
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`
|
|
and use rustc_hir_pretty directly instead
|
|
Properly handle primitive disambiguators in rustdoc
Fixes #80559
r? ``@jyn514``
Is there a way to test that the generated intra-doc link is what I expect?
|
|
|
|
|