-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo clippy -- -W help
runs clippy
#6122
Comments
Will take a look to fix that as a first contribution to clippy :) |
Signed-off-by: Benjamin Coenen <[email protected]>
Signed-off-by: Benjamin Coenen <[email protected]>
Signed-off-by: Benjamin Coenen <[email protected]>
@lnicola You can get the list of clippy lints with @bnjjj asked about adding a flag to display the lint list in @bnjjj Thanks for your work! Even though your PR won't get merged, it helped to figure out what is going on and is therefore much appreciated! If you want to improve the situation with Also this message at the end of the output of
|
The problem I see with that approach is that it requires providing a crate, while the manual handling of (pointing this out because it was one of the concerns in the OP) |
Yeah, I wondered why and went investigating. Because from a UX perspective it doesn't make sense, that I found this code snippet, which is executed if We could easily modify this with diff --git a/compiler/rustc_driver/src/lib.rs b/compiler/rustc_driver/src/lib.rs
index 3f50c68e3eb..bae45c12058 100644
--- a/compiler/rustc_driver/src/lib.rs
+++ b/compiler/rustc_driver/src/lib.rs
@@ -206,11 +206,18 @@ pub fn run_compiler(
interface::run_compiler(config, |compiler| {
let sopts = &compiler.session().opts;
if sopts.describe_lints {
- let lint_store = rustc_lint::new_lint_store(
+ let mut lint_store = rustc_lint::new_lint_store(
sopts.debugging_opts.no_interleave_lints,
compiler.session().unstable_options(),
);
- describe_lints(compiler.session(), &lint_store, false);
+ let registered_lints =
+ if let Some(register_lints) = compiler.register_lints() {
+ register_lints(compiler.session(), &mut lint_store);
+ true
+ } else {
+ false
+ };
+ describe_lints(compiler.session(), &lint_store, registered_lints);
return;
}
let should_stop = RustcDefaultCalls::print_crate_info(
diff --git a/compiler/rustc_interface/src/interface.rs b/compiler/rustc_interface/src/interface.rs
index 73a51ad477b..11dd6ec32c0 100644
--- a/compiler/rustc_interface/src/interface.rs
+++ b/compiler/rustc_interface/src/interface.rs
@@ -56,6 +56,9 @@ impl Compiler {
pub fn output_file(&self) -> &Option<PathBuf> {
&self.output_file
}
+ pub fn register_lints(&self) -> &Option<Box<dyn Fn(&Session, &mut LintStore) + Send + Sync>> {
+ &self.register_lints
+ }
pub fn build_output_filenames(
&self,
sess: &Session, which then should always print all lints, if there is a plugin (or something else that registers lints). |
…anishearth 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#6122 cc `@Manishearth` `@ebroto` for the Clippy changes.
Originally posted by @lnicola in #5385 (comment)
Even though the
-Whelp
thing is unstable, it shouldn't have to run Clippy on a crate to print out the help message with all lints.The text was updated successfully, but these errors were encountered: