cargo check no longer shows warnings unconditionally

[ashtneoi]

In the past, cargo check would always show every warning that a cargo clean && cargo build would show, even if there were no errors and I'd already run cargo check. For example, if I had an unused variable, cargo check would print something like this every time I ran it, regardless of file timestamps or build artifacts:

$ cargo check
   Compiling asht v0.1.0 ([redacted])
warning: unused variable: `a`
 --> src/main.rs:2:9
  |
2 |     let a = 3;
  |         ^ help: consider using `_a` instead
  |
  = note: #[warn(unused_variables)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.21 secs

Recently the behavior changed, and now cargo check only shows warnings if I touch the source code or delete the build artifacts. Otherwise, it just acts the same as cargo build does when the build is up to date:

$ cargo check
    Finished dev [unoptimized + debuginfo] target(s) in 0.12 secs

The first nightly release with the new behavior is nightly-2018-04-15. The change seems to have been caused by rustc, and a bisect of the rust-lang/rust repo showed commit 2a5f3ee0c5b5 as the culprit. I'm not familiar with the Rust build system, but I did notice that for a binary crate, deleting any of the following files will make cargo check print warnings the next time I run it:

• target/debug/lib{name}.rmeta
• target/debug/deps/lib{name}-{id}.rmeta
• target/debug/.fingerprint/{name}-{id}/bin-{name}-{id}
• target/debug/.fingerprint/{name}-{id}/dep-bin-{name}-{id}

I don't know if this is technically a bug report or a feature request. Let me know if I should file it against rust instead of Cargo.

versions

The last Rust release with the old behavior is nightly-2018-04-12, which has Cargo version 1.26.0-nightly (b70ab13b3 2018-04-04).

The first Rust release with the new behavior is nightly-2018-04-15, which has Cargo version 1.26.0-nightly (008c36908 2018-04-13).

I got both of those releases through rustup. The specific version of Cargo doesn't seem to matter, though, since (as I mentioned) it was a rustc change that caused the behavior change.

[alexcrichton]

I believe this is a consequence of rust-lang/rust#49289 which should unify the behavior of libraries and binaries

[ashtneoi]

Is this expected behavior then? (Which is fine---the workaround is easy enough.)

[alexcrichton]

Currently, yeah, I believe this is expected behavior

[ashtneoi]

My apologies, I forgot to include closed issues when I looked for existing issues about this, so I missed the prior discussions linked from #5236. You can close this one as a dupe if you want.

[alexcrichton]

Ok and no worries! I'll go ahead and close this