Always print lints from plugins, if they're available #77671

flip1995 · 2020-10-07T20:55:16Z

Currently you can get a list of lints and lint groups by running rustc -Whelp. This prints an additional line at the end:

Compiler plugins can provide additional lints and lint groups. To see a listing of these, re-run `rustc -W help` with a crate filename.

Clippy is such a "compiler plugin", that provides additional lints.
Running clippy-driver -Whelp (rustc wrapper) still only prints the
rustc lints with the above message at the end. But when running
clippy-driver -Whelp main.rs, where main.rs is any rust file, it
also prints Clippy lints. I don't think this is a good approach from a
UX perspective: Why is a random file necessary to print a help message?

This PR changes this behavior: Whenever a compiler callback
registers lints, it is assumed that these lints come from a plugin and
are printed without having to specify a Rust source file.

Fixes rust-lang/rust-clippy#6122

cc @Manishearth @ebroto for the Clippy changes.

rust-highfive · 2020-10-07T20:55:20Z

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

Manishearth · 2020-10-07T20:56:51Z

r+ on making this happen, I'll let eddy review the PR (though i should be able to if i get time)

ebroto

Clippy part LGTM 👍

bors · 2020-11-24T09:29:07Z

☔ The latest upstream changes (presumably #79228) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

Currently you can get a list of lints and lint groups by running `rustc -Whelp`. This prints an additional line at the end: ``` Compiler plugins can provide additional lints and lint groups. To see a listing of these, re-run `rustc -W help` with a crate filename. ``` Clippy is such a "compiler plugin", that provides additional lints. Running `clippy-driver -Whelp` (`rustc` wrapper) still only prints the rustc lints with the above message at the end. But when running `clippy-driver -Whelp main.rs`, where `main.rs` is any rust file, it also prints Clippy lints. I don't think this is a good approach from a UX perspective: Why is a random file necessary to print a help message? This commit changes this behavior: Whenever a compiler callback registers lints, it is assumed that these lints come from a plugin and are printed without having to specify a Rust source file.

Also stop updating the lintlist module in clippy_dev update_lints

flip1995 · 2020-11-24T09:43:03Z

@eddyb @Manishearth This PR is 1 1/2 months old and waiting for review. This would be nice to have from a Clippy perspective.

lnicola · 2020-11-24T09:46:43Z

For more context, it's also useful for rust-analyzer because it can use it to offer completions for #[allow] and #[deny] attributes.

flip1995 · 2020-11-24T15:54:20Z

For more context, it's also useful for rust-analyzer because it can use it to offer completions for #[allow] and #[deny] attributes.

Oh right, that's why I did this in the first place. I already forgot lol 😄

Manishearth · 2020-11-24T18:08:30Z

compiler/rustc_driver/src/lib.rs

-                "Compiler plugins can provide additional lints and lint groups. To see a \
-                      listing of these, re-run `rustc -W help` with a crate filename."
-            );
+            println!("Compiler plugins can provide additional lints and lint groups.");


let's actually just get rid of this? It's not relevant to clippy, and compiler plugins are not a common thing.

I reworded it in e54c060. Removing this would also involve dealing with this case in the match statement somehow. I think printing a message, that tools can provide more lints is a good way to deal with this case.

Manishearth · 2020-11-24T18:08:59Z

src/tools/clippy/src/lintlist/mod.rs

@@ -1,2942 +0,0 @@
-//! This file is managed by `cargo dev update_lints`. Do not edit or format this file.


oli-obk · 2020-11-26T10:12:13Z

@bors r=oli-obk,Manishearth

bors · 2020-11-26T10:12:14Z

📌 Commit e54c060 has been approved by oli-obk,Manishearth

bors · 2020-11-26T10:12:15Z

🌲 The tree is currently closed for pull requests below priority 500, this pull request will be tested once the tree is reopened

oli-obk · 2020-11-26T10:12:22Z

r? @oli-obk

bors · 2020-11-26T18:51:53Z

⌛ Testing commit e54c060 with merge 72da5a9...

bors · 2020-11-26T21:00:59Z

☀️ Test successful - checks-actions
Approved by: oli-obk,Manishearth
Pushing 72da5a9 to master...

…oli-obk,Manishearth Always print lints from plugins, if they're available Currently you can get a list of lints and lint groups by running `rustc -Whelp`. This prints an additional line at the end: ``` Compiler plugins can provide additional lints and lint groups. To see a listing of these, re-run `rustc -W help` with a crate filename. ``` Clippy is such a "compiler plugin", that provides additional lints. Running `clippy-driver -Whelp` (`rustc` wrapper) still only prints the rustc lints with the above message at the end. But when running `clippy-driver -Whelp main.rs`, where `main.rs` is any rust file, it also prints Clippy lints. I don't think this is a good approach from a UX perspective: Why is a random file necessary to print a help message? This PR changes this behavior: Whenever a compiler callback registers lints, it is assumed that these lints come from a plugin and are printed without having to specify a Rust source file. Fixes rust-lang/rust-clippy#6122 cc `@Manishearth` `@ebroto` for the Clippy changes.

rust-highfive assigned eddyb Oct 7, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 7, 2020

ebroto approved these changes Oct 7, 2020

View reviewed changes