Don't warn about old rustdoc lint names (temporarily) #83203
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jyn514
added
T-rustdoc
rust-highfive
added
the
S-waiting-on-review
|
The stable release is in 9 days, but beta is usually promoted 6 days before (this Friday, the 19th). I think we should backport this to 1.52.0 beta if it doesn't make the cutoff. |
This comment has been minimized.
This comment has been minimized.
jyn514
force-pushed
the
rustdoc-warnings
branch
from
fa262fa
to
7b0ca97
Compare
This comment has been minimized.
This comment has been minimized.
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.
jyn514
force-pushed
the
rustdoc-warnings
branch
from
7b0ca97
to
c1b99f0
Compare
GuillaumeGomez
approved these changes
Mar 16, 2021
|
@bors r+ cc @rust-lang/clippy these functions may be useful to us too |
|
📌 Commit c1b99f0 has been approved by |
bors
added
S-waiting-on-bors
I was thinking that we might want to wait longer because people will have to bump their MSRV to use the new names. But we also don't want to wait forever, so 🤷 |
|
So I would wait a little bit longer to enable linting on this, and then much longer to turn the old ones into no-ops (if ever) |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 17, 2021
Rollup of 8 pull requests Successful merges: - rust-lang#82774 (Fix bad diagnostics for anon params with ref and/or qualified paths) - rust-lang#82826 ((std::net::parser): Fix capitalization of IP version names) - rust-lang#83092 (More precise spans for HIR paths) - rust-lang#83124 (Do not insert impl_trait_in_bindings opaque definitions twice.) - rust-lang#83202 (Show details in cfg version unstable book) - rust-lang#83203 (Don't warn about old rustdoc lint names (temporarily)) - rust-lang#83206 (Update books) - rust-lang#83219 (Update cargo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 4, 2021
Warn when `rustdoc::` group is omitted from lint names When rustdoc lints were first made a tool lint, they gave an unconditional warning when you used the original name: ``` warning: lint `broken_intra_doc_links` has been renamed to `rustdoc::broken_intra_doc_links` --> $DIR/renamed-lint-still-applies.rs:2:9 | LL | #![deny(broken_intra_doc_links)] | ^^^^^^^^^^^^^^^^^^^^^^ help: use the new name: `rustdoc::broken_intra_doc_links` | = note: `#[warn(renamed_and_removed_lints)]` on by default ``` That was reverted in rust-lang#83203 because adding `rustdoc::x` lints would cause the code to break on old versions of the compiler (due to rust-lang#66079 (comment), "fixed" in rust-lang#83216 in the sense that you can now opt-in to not breaking on nightly, which is not ideal but `register_tool` is a long way from stabilizing). Since rust-lang#80527 is now on 1.52.0 stable, we can re-enable the warning. For nightly users, they can change immediately and still have their code work on stable; for stable users, they can change their code in 12 weeks and still have it work up to 3 releases back (about 18 weeks). That seems reasonable to me. r? `@Manishearth` cc `@rust-lang/rustdoc`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since #80527, 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 (#66079 (comment)). 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
rustdoctool name makes it to the stable channel, we can change these lints to warn again.This adds the new lint functions
register_aliasandregister_ignored- I didn't see an existing way to do this.r? @Manishearth cc @rust-lang/rustdoc