Running cargo check after having run cargo clippy reports clippy errors

[camelid]

cargo check reports clippy errors and warnings after having run cargo clippy.

Steps to reproduce

1. Add some code that clippy will lint on but rustc will not
2. Run cargo clippy -- observe some errors and warnings
3. Run cargo check -- observe the errors and warnings produced by clippy!

Running cargo clean fixes this, but that's kind of unfortunate. I'm guessing this is related to #3837 re check and clippy sharing a build cache.

Meta

• cargo clippy -V: clippy 0.0.212 (18bf6b4f0 2020-10-07)
• rustc -Vv:

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-apple-darwin
release: 1.47.0
LLVM version: 11.0

[camelid]

Likewise, and more concerning, running cargo check and then cargo clippy hides clippy errors.

[ebroto]

This is probably #4612

Can you check if the behavior disappears if using cargo +nighly clippy -Z unstable-options ?

[camelid]

Example

Setup

1. Run cargo new clippy-issue-6253
2. Set src/main.rs to this:

fn main() {
    let _ = 1.0 == 1.0;
}

clippy, then check, then clippy

$ cargo clippy
    Checking clippy-issue-6253 v0.1.0 (/Users/user/clippy-issue-6253)
error: equal expressions as operands to `==`
 --> src/main.rs:2:13
  |
2 |     let _ = 1.0 == 1.0;
  |             ^^^^^^^^^^
  |
  = note: `#[deny(clippy::eq_op)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#eq_op

error: strict comparison of `f32` or `f64`
 --> src/main.rs:2:13
  |
2 |     let _ = 1.0 == 1.0;
  |             ^^^^^^^^^^ help: consider comparing them within some error: `(1.0 - 1.0).abs() < error`
  |
  = note: `#[deny(clippy::float_cmp)]` on by default
  = note: `f32::EPSILON` and `f64::EPSILON` are available for the `error`
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#float_cmp

error: aborting due to 2 previous errors

error: could not compile `clippy-issue-6253`.

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

$ cargo check
    Checking clippy-issue-6253 v0.1.0 (/Users/user/clippy-issue-6253)
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s

$ cargo clippy
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s

check then clippy

I ran cargo clean after the previous step to clear the build cache.

$ cargo check
    Checking clippy-issue-6253 v0.1.0 (/Users/user/clippy-issue-6253)
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s

$ cargo clippy
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s

[mati865]

This is probably #4612

Yes, it's cargo issue that Clippy cannot fix.

[camelid]

Can you check if the behavior disappears if using cargo +nighly clippy -Z unstable-options ?

@ebroto Yes, it works as expected with that command. Do you know how long it will be until that's stable?

[ebroto]

This is rust-lang/cargo#8143.

We're currently working towards stabilizing that. #6188 is one step forward, which I plan to finish after hacktoberfest is over and I can catch a break from reviewing :)

[ebroto]

I'm going to close this issue since it seems to be a duplicate.

Thanks for your report anyway!