You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, awesome tool and using it has been helping me learn Rust!
I've been trying to automate executing clippy from some scripts I run across a number of crates I'm maintaining at the moment, and it's tricky to check if there was any warnings from clippy from a Bash script.
I'd love if there was a flag I could set to trigger non-zero exit statuses for any warnings so I can use clippy meaningfully from my scripts. Apologies if something like this already exists and I've just missed it, running clippy --help doesn't appear to show anything relevant though.
alexwlchan, nils-ohlmeier, sanmai-NL, mcandre, l0b0 and 50 more
The return code is handled by rustc itself. However in a script, it would be much easier to use JSON output:
% rustc a.rs
warning: unused variable: `a`, #[warn(unused_variables)] on by default
--> a.rs:2:9
|
2 | let a = 42;
| ^
% rustc --error-format json a.rs
{"message":"unused variable: `a`, #[warn(unused_variables)] on by default","code":null,"level":"warning","spans":[{"file_name":"a.rs","byte_start":20,"byte_end":21,"line_start":2,"line_end":2,"column_start":9,"column_end":10,"is_primary":true,"text":[{"text":" let a = 42;","highlight_start":9,"highlight_end":10}],"label":null,"suggested_replacement":null,"expansion":null}],"children":[],"rendered":null}
(you get one line per error/warning, which is a json object describing the error)
@mcarton: that does not clearly separate between messages generated by Clippy and other messages. For instance, the compiler aborting due to previous Clippy-induced errors is considered an error in itself.
Moreover, Cargo writes these machine readable JSON messages on standard error instead of standard output, resulting in unparseable about (a mixture of exclusively human and machine readable output).
Compiling something v0.1.0 (file:///tmp/something)
warning: used unwrap() on a Result value. If you don't want to handle the Err case gracefully, consider using expect() to provide a better panic message
--> something/src/main.rs:19:41
|
19 | let service = const_service(create_new_service(data).unwrap());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: lint level defined here
--> something/src/main.rs:8:44
|
8 | #![cfg_attr(feature = "cargo-clippy", warn(clippy_pedantic))]
| ^^^^^^^^^^^^^^^
= note: #[warn(result_unwrap_used)] implied by #[warn(clippy_pedantic)]
= help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.186/index.html#result_unwrap_used
Finished dev [unoptimized + debuginfo] target(s) in 48.81 secs
echo$?
0
cpick, OJFord, niedzielski, Kobzol, lovasoa and 3 more
oliver@iai-matthes1:~/Projects/rust/cargo_metadata$ cargo +nightly clippy --frozen --all-features --package cargo_metadata -- -Dwarnings
lib: cargo_metadata
Compiling cargo_metadata v0.5.0 (file:///home/oliver/Projects/rust/cargo_metadata)
error: this expression borrows a reference that is immediately dereferenced by the compiler
--> src/lib.rs:199:46
|
199 | let version = semver::Version::parse(&version).map_err(de::Error::custom)?;
| ^^^^^^^^ help: change this to: `version`
|
= note: `-D needless-borrow` implied by `-D warnings`
= help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.186/index.html#needless_borrow
error: redundant field names in struct initialization
--> src/lib.rs:204:13
|
204 | version: version,
| ^^^^^^^^^^^^^^^^ help: replace it with: `version`
|
= note: `-D redundant-field-names` implied by `-D warnings`
= help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.186/index.html#redundant_field_names
error: aborting due to 2 previous errors
error: Could not compile `cargo_metadata`.
To learn more, run the command again with --verbose.
oliver@iai-matthes1:~/Projects/rust/cargo_metadata$ echo $?
101
It was in a lib project without workspaces though.
@oli-obk: what can we do here? Can you or someone else who wishes to confirm take some more time to test with a virtual workspace? If this snag is resolved then this GitHub issue could, as far as I am concerned, be closed. So it seems worthwhile to test and even add a test case if there turns out to be a bug.
I don't think forbidding warnings is enough. For example, when I have two packages in workspace, -D warnings causes clippy to stop after some warnings are encountered in first package, thus not checking the second one at all.
Moreover this is awkward to use in CI in non-blocking mode. I'd like to know number of hard errors and number of warnings. Hard errors should block CI, but not the warnings.
Note that rust-lang/rust#87337 only avoids failing fast within the crate; if you have multiple crates in a workspace, cargo will still stop after the first one with a denied warning.
@jyn514 i see...., may i know what is the motivation of this design? I feel either make it configurable that totally not failing fast, or something like only after encountered certain number of denies then fail is better? Instead of like currently fail at 1st, then push then fail at another, so on and on, a bit annoying
This still doesn't work between crates in a workspace, only within individual crates. Doing it for the whole workspace requires cargo support: rust-lang/rust#82761 (comment)
Activity
mcarton commentedon Sep 2, 2016
The return code is handled by rustc itself. However in a script, it would be much easier to use JSON output:
(you get one line per error/warning, which is a json object describing the error)
sanmai-NL commentedon Feb 17, 2018
@mcarton: that does not clearly separate between messages generated by Clippy and other messages. For instance, the compiler aborting due to previous Clippy-induced errors is considered an error in itself.
Moreover, Cargo writes these machine readable JSON messages on standard error instead of standard output, resulting in unparseable about (a mixture of exclusively human and machine readable output).
oli-obk commentedon Feb 19, 2018
You can pass
-Dwarnings
to ensure that warnings are treated as errors. This way you'll also get the non-zero exit code.sanmai-NL commentedon Feb 19, 2018
@oli-obk: Does that work if you set the lint level to
warn
for every lint (group), via attributes?oli-obk commentedon Feb 20, 2018
@sanmai-NL yes
sanmai-NL commentedon Feb 20, 2018
@oli-obk:
It doesn’t work for me.
something
is a crate with onebin
target, member of a virtual workspace.something/src/main.rs
:oli-obk commentedon Feb 21, 2018
It works fine on my machine :/
It was in a lib project without workspaces though.
sanmai-NL commentedon Feb 21, 2018
@oli-obk: what can we do here? Can you or someone else who wishes to confirm take some more time to test with a virtual workspace? If this snag is resolved then this GitHub issue could, as far as I am concerned, be closed. So it seems worthwhile to test and even add a test case if there turns out to be a bug.
oli-obk commentedon Feb 21, 2018
@sanmai-NL If you give me a repro example (upload your example to github?) I can investigate further
niedhui commentedon Jun 20, 2018
@oli-obk I had the same problem as @sanmai-NL , the output said
error: aborting due to 12 previous errors
, which followed byFinished dev [unoptimized + debuginfo] target(s) in 1m 18s
, and the returned status is 0 (checked on my machine). here is the ci job link https://travis-ci.org/niedhui/rust-prometheus/jobs/394541190#L1948cargo clippy
instead of the clippy plugin #176 tikv/rust-prometheus#184cpick commentedon Jun 20, 2018
I ran into this as well.
I can reproduce with the following Dockerfile:
Which when built with
sudo docker build .
erroneously succeeds:oli-obk commentedon Jun 21, 2018
Fixed in #2863
Now we just need a regression test. Probably just adding something to travis is enough.
mkpankov commentedon Oct 15, 2019
I don't think forbidding warnings is enough. For example, when I have two packages in workspace,
-D warnings
causes clippy to stop after some warnings are encountered in first package, thus not checking the second one at all.Moreover this is awkward to use in CI in non-blocking mode. I'd like to know number of hard errors and number of warnings. Hard errors should block CI, but not the warnings.
7 remaining items
jyn514 commentedon Dec 1, 2021
Note that rust-lang/rust#87337 only avoids failing fast within the crate; if you have multiple crates in a workspace, cargo will still stop after the first one with a denied warning.
lnshi commentedon Dec 2, 2021
@jyn514 i see...., may i know what is the motivation of this design? I feel either make it configurable that totally not failing fast, or something like only after encountered certain number of denies then fail is better? Instead of like currently fail at 1st, then push then fail at another, so on and on, a bit annoying
jyn514 commentedon Dec 2, 2021
@lnshi "it's hard" and no one has done the work to implement it.
github: make sure clippy job fail if any warning emitted
github: make sure clippy job fail if any warning emitted
github: make sure clippy job fail if any warning emitted
lquenti commentedon Jul 16, 2022
Why is this issue still open? Seems pretty fixed to me
jyn514 commentedon Jul 16, 2022
This still doesn't work between crates in a workspace, only within individual crates. Doing it for the whole workspace requires cargo support: rust-lang/rust#82761 (comment)
kpreid commentedon Jul 21, 2024
Here are two more reasons why a separate flag would be an improvement over
-Dwarnings
for this purpose:cargo clippy
, so you have to wait longer if the other command is run for any reason.An option that changed the exit status behavior only would not have these disadvantages.
Alexendoo commentedon Aug 24, 2024
Tracking #1209 (comment) in #12623
For the cargo feature that will be rust-lang/cargo#8424
clippy --fix -- -Dwarnings
does not fail on warnings #13502