Rust-clippy: Clippy doesn't report error/warnings after cargo check

[b1zzu]

Environment

Project: https://github.com/b1zzu/wifiscanner/tree/clippy-bug (use the clippy-bug branch`)
Cargo: cargo 1.38.0 (23ef9a4ef 2019-08-20)
Clippy: clippy 0.0.212 (3aea860 2019-09-03)

Steps to reproduce

Run cargo clippy after cargo check

cargo check
cargo clippy

Clippy doesn't fail or display any errors.

Expected result

cargo clippy should fails with this errors:

warning: Constants have by default a `'static` lifetime
  --> src/lib.rs:87:22
   |
87 |     const PATH_ENV: &'static str = "PATH";
   |                     -^^^^^^^---- help: consider removing `'static`: `&str`
   |
   = note: `#[warn(clippy::redundant_static_lifetimes)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_static_lifetimes

error: approximate value of `f{32, 64}::consts::PI` found. Consider using it directly
  --> src/lib.rs:85:14
   |
85 |     let _x = 3.14;
   |              ^^^^
   |
   = note: `#[deny(clippy::approx_constant)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#approx_constant

warning: single-character string constant used as pattern
   --> src/lib.rs:157:16
    |
157 |         .split("\n")
    |                ^^^^ help: try using a char instead: `'\n'`
    |
    = note: `#[warn(clippy::single_char_pattern)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#single_char_pattern

warning: single-character string constant used as pattern
   --> src/lib.rs:168:36
    |
168 |     for line in network_list.split("\n") {
    |                                    ^^^^ help: try using a char instead: `'\n'`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#single_char_pattern

error: aborting due to previous error

error: Could not compile `wifiscanner`.

To learn more, run the command again with --verbose.

Workaround

cargo check
cargo clean
cargo clippy

[mati865]

The only reasonable way to fix it is https://github.com/rust-lang/rust-clippy/issues/3837

With nightly toolchain you can use cargo clippy-preview -Z unstable-options as workaround.

[b1zzu]

@mati865 for now I will use cargo clean before clippy

[matthiaskrgr]

It works better if you touch all files of your root crate, this way you don't have to rebuild all the dependencies every time:

find . | grep "\.rs$" | xargs touch ; cargo clippy

[flip1995]

I think we should document this (find . | grep "\.rs$" | xargs touch ; cargo clippy) until cargo clippy (in cargo) is stable.

[b1zzu]

@flip1995 where would you document it? In a new separate Troubleshooting section or as a comment/tips to the step-3-run-clippy

[flip1995]

I think at step-3-run-clippy is enough, since it will be removed anyway in the near future.

[maxbla]

This issue can also be triggered by running clippy multiple times with different options.
main.rs

fn main() {
    let _1 = 1_usize;
    println!("{}", _1);
}

$ cargo clean
$ cargo clippy -- --deny clippy::just_underscores_and_digits
    Compiling ...
error: consider choosing a more descriptive name
...
$ cargo clippy -- --allow clippy::all
$ cargo clippy -- --deny clippy::just_underscores_and_digits

cargo clean fixes this manifestation of the problem also

[sourcefrog]

It looks like this is now fixed?

cargo check
cargo clippy

shows the right errors every time I run it.

clippy 0.0.212 (69f99e7 2019-12-14)
cargo 1.41.0 (626f0f40e 2019-12-03)

[flip1995]

That would surprise me, because we didn't change anything.

I just tested https://github.com/rust-lang/rust-clippy/issues/4612#issuecomment-563213742 and the behavior didn't change there.

[humb1t]

Clippy still depends on check: clippy 0.0.212 (4ee1206 2020-02-01)

[najamelan]

The only reasonable way to fix it is #3837

What about having cargo clippy run the touch **.rs workaround itself? It would depend on platform support for the touch command and globbing, but I feel this issue is important enough to try this.

[mati865]

What about having cargo clippy run the touch **.rs workaround itself?

You can just make a script that will call touch and Clippy.

[humb1t]

@mati865 don't you think that this is not a solution?
Imagine that cargo test will not run tests if cargo build was already executed.

[mati865]

@humb1t neither modifying files without permission is the solution.

[flip1995]

This is now fixed when running Clippy with

cargo clippy -Zunstable-options

on nightly.

[humb1t]

@mati865 totally agree with you

[matthiaskrgr]

The feature should be available as soon as nightly 2020-04-18 rolls out.

[saleemrashid]

If I run the following commands (in this order) in my workspace, which has some dead_code, all the commands work as expected

# dead_code errors
cargo clippy -Z unstable-options -- -D warnings
# dead_code + clippy::restriction errors
cargo clippy -Z unstable-options -- -D warnings -D clippy::restriction
# dead_code errors
cargo clippy -Z unstable-options -- -D warnings

However, if I use warnings instead of errors, the first invocation's output is cached.

# dead_code warnings
cargo clippy -Z unstable-options
# dead_code warnings
cargo clippy -Z unstable-options -- -W clippy::restriction
find -name "*.rs" -exec touch {} \;
# dead_code + clippy::restriction warnings
cargo clippy -Z unstable-options -- -W clippy::restriction
# dead_code + clippy::restriction warnings
cargo clippy -Z unstable-options

Not sure if I'm using an outdated Clippy version, none of the comments seem to specify which is the "fixed" nightly, or even link to the relevant pull request.

---

rustc 1.44.0-nightly (b2e36e6c2 2020-04-22)
clippy 0.0.212 (891e1a8 2020-04-18)

[flip1995]

You should be using the nightly where this is already included.

@yaahc any ideas?

[saleemrashid]

Here's a shorter reproduction case

echo "fn unused() {}" > src/lib.rs
cargo clippy -Z unstable-options
cargo clippy -Z unstable-options -- --allow dead_code
touch src/lib.rs
cargo clippy -Z unstable-options -- --allow dead_code
cargo clippy -Z unstable-options

---

Note that it works fine with errors, but not warnings.

echo "pub fn bad() -> bool { 0 <= 0 }" > src/lib.rs
cargo clippy -Z unstable-options
cargo clippy -Z unstable-options -- --allow clippy::eq_op
touch src/lib.rs
cargo clippy -Z unstable-options -- --warn clippy::all
cargo clippy -Z unstable-options -- --allow clippy::eq_op

---

rustc 1.44.0-nightly (b2e36e6c2 2020-04-22)
cargo 1.44.0-nightly (8751eb301 2020-04-21)
clippy 0.0.212 (891e1a8 2020-04-18)

[yaahc]

This is probably an issue with cargo, I'll check it out tomorrow.

cc @ehuss

[ehuss]

The caching with different flags is https://github.com/rust-lang/cargo/issues/7862. The issue is twofold. One is that clippy hides the flags from cargo (via __CLIPPY_HACKERY__). The other is that Cargo doesn't provide a way to hash flags.

EDIT: I haven't looked into this, but I'm uncertain why clippy uses the flag hack. If it used RUSTFLAGS instead, it might just work? Something worth investigating.

[retep998]

I'm running into this a lot because rust-analyzer will automatically run cargo check on save, so when I decide to run cargo clippy it doesn't report anything.

[flip1995]

@ehuss Is there a plan to stabilize the RUSTC_WORKSPACE_WRAPPER env var in cargo in the near future, so that we can get this to stable? Since this is an issue, that comes up a few times a month, I'd be willing to put in the work, if there is still something to do before stabilization.

[ehuss]

There is an issue identified at https://github.com/rust-lang/cargo/issues/8143#issuecomment-619289546. I think it would be good to at least have a design plan (and preferably an implementation) to fix that before stabilizing, in case it influences how the wrapper should work.

[jonasmalacofilho]

Knowing that the problem is the reuse of metadata from regular/other check runs, I found that running clippy with a different --target-dir is sufficient to work around the problem.

$ cargo check
$ cargo clippy -- [clippy options]
[... nothing ...]
$ cargo clippy --target-dir target/clippy -- [clippy options]
[... clippy warnings and errors ...]

Note that I don't think this will necessarily do the right thing when workspaces are involved, particularly if cargo clippy is not invoked from the workspace root.

[lf-]

By the way, if anyone is having annoying issues with rust-analyzer running cargo check on save so your clippy doesn't work, you can do cargo clippy --release without having to introduce a separate feature.

Also, is this related to https://github.com/rust-lang/rust-clippy/issues/2604?

[flip1995]

Also, is this related to #2604?

Yes this is basically the same