cargo clippy is no-op when edition = 2018

[k-stanislawek]

Problem

cargo clippy is not running clippy when edition = 2018. It's also not providing any feedback. It works correctly on edition = 2015.

# set edition to 2018 in Cargo.toml
$ cargo clippy -vv
       Fresh reproclippy v0.1.0 (/home/ks/workdir/rust/reproclippy)
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s

# Empty output - meanwhile, calling "clippy-driver" directly (implicitly in 2015 mode) generates non-empty output:

$ clippy-driver src/main.rs 
warning: casting a character literal to `u8` truncates
[...]

Various component versions are listed below - it's nightly.

Note that it could as well be caused by clippy misbehaving on version = 2018, but I have no way to test this, since neither cargo nor clippy doesn't expose any information on calling clippy directly with non-default edition. Either way I blame cargo, either for a bug, or for lack of feedback that I could use to prove that it's clippy fault.

It worked around January/February, I'm not sure when it stopped (likely a good few months ago, because I've seen empty output but haven't checked if it's working correctly).

$ cat Cargo.toml 
[package]
name = "reproclippy"
version = "0.1.0"
authors = ["redacted"]
edition = "2018"
[dependencies]

$ rustup show active-toolchain
nightly-x86_64-unknown-linux-gnu (default)

$ rustup show profile
default

$ clippy-driver --version
clippy 0.0.212 (346aec9 2020-07-11)

$ cargo --version
cargo 1.46.0-nightly (4f74d9b2a 2020-07-08

Steps

Just set up a new default project using Nightly toolchain, add something like let foo = 3; and test using cargo clippy and clippy-driver src/main.rs.

[k-stanislawek]

Side issue - there is no way to drill into what cargo clippy does on the inside. I would expect such option from a wrapper-like tool. I could use it to figure out whether it's cargo problem, or clippy problem.

Is it feasible feature request to add logging (in like a 2nd or 3rd verbosity level) for all commands called from cargo master process?

[ehuss]

I believe you are seeing that clippy shares the cache with cargo check. If you run cargo check, then it won't run clippy because it believes it has already completed. You can run cargo +nightly clippy -Zunstable-options to avoid the caching. There are more details at #8143 and rust-lang/rust-clippy#4612 and rust-lang/rust-clippy#3837.

As for logging, the CARGO_LOG environment variable can be used to provide debugging information about cargo's behavior. For example CARGO_LOG=cargo::core::compiler::fingerprint=trace will display information about cargo's fingerprinting.

[k-stanislawek]

@ehuss I see... Any chance for quick solution to avoid confusion? E.g. extra prompt message after running "cargo clippy"? Like "Compiling modified modules using clippy" (or whatever is happening actually). I appreciate there is complete solution in pipeline, but it seems months away, while the problem (miscommunication) appears to be trivial to fix.

For CARGO_LOG, looks useful, is it documented anywhere?

[ehuss]

You will need to follow up with the clippy team (either in one of the linked issues above, or file a new issue on their repo, or ask on Discord).

As for CARGO_LOG, it is mostly undocumented, as it is normally only used for debugging. It is mentioned here for contributors. It tends to be very low-level, and not easily usable by end-users.

[ehuss]

I'm going to close this as the relevant issues are tracked in the issues linked above.