Cargo clean --package doesn't clean all targets if package defines features

[davidlattimore]

At least I think that's what's happening.

Setup:

cargo new --lib p1
cd p1
echo '[features]' >>Cargo.toml
echo 'something = []' >>Cargo.toml

Then run:

cargo clean --package p1 && cargo check -v --tests
cargo clean --package p1 && cargo check -v --tests

Expected:
Since we did a cargo clean of package p1 in between runs of cargo check, I'd expect that the second run should invoke rustc.

Actual:
rustc is only invoked the fist time

Notes:
Doing a full clean (without --package) behaves as expected (rustc invoked both times).
If I don't declare any features in Cargo.toml, then it behaves as expected.

This problem is especially evident if there's a warning inside some #[cfg(test)] code. Once you've compiled once, you can't get the warning back without either (a) editing the file or (b) doing a full clean. i.e. cleaning just the local package then doing a new cargo check isn't sufficient.

Tested on:
cargo 1.26.0-nightly (008c369 2018-04-13)

[joelgallant]

This problem is especially evident if there's a warning inside some #[cfg(test)] code. Once you've compiled once, you can't get the warning back without either (a) editing the file or (b) doing a full clean. i.e. cleaning just the local package then doing a new cargo check isn't sufficient.

This also applies to linting - my CI runs were spuriously giving lint errors, which I realized was because clippy was not re-running.

[dwijnand]

@joelgallant By "also applies to linting" I assume you mean clippy linting, which is tracked as rust-lang/rust-clippy#2604.

[dwijnand]

Perhaps the cause here is the same as described in #3530:

My hypothesis (which @alexcrichton confirmed) is that each generates a distinct fingerprint, and cargo clean -p foo is looking for a version with no arguments.