I recently failed to notice an improper use of write (when I should have been using write_all) in my code that was treated as a hard warning by Clippy.
However, I failed to find the issue with clippy, because cargo clippy and cargo check both gave me no output (other than the “Finished…” message), regardless of what command line arguments I used.
I find this behavior surprising and footgun-y. I wasn’t doing anything strange with my setup or Clippy usage (incremental compilation is on by default), and I wasn’t aware of this as a possible pitfall; I only discovered the problem because someone else happened to run Clippy on a clean copy of my codebase. (Even then, neither of us suspected that the state of the target folder would impact Clippy’s behavior, so it took me a while to even try cargo clean.)
So I have a few questions:
- Is there an easy way to force Clippy to re-evaluate all code without actually deleting the cached build output? I shouldn’t need to delete correctly-compiled code just to apply a linter. (Obviously I could do this in Bash:
mv target{,.hide}; cargo clippy; rm -rf target/; mv target{.hide,} … but that seems like a kludge.) Would temporarily turning off incremental compilation force Clippy to perform a full analysis?
- How can I advocate/facilitate/design a fix for this issue? Even a warning like “some source files skipped because they have already been compiled” would at least give the user a heads-up about what’s going on. But ideally, the set of warnings and errors emitted by Clippy would never depend on the state of
target, only on the state of src.
- Once this issue has been addressed for Clippy, would it be reasonable to push for a similar feature in
rustc/cargo that would somehow cache warnings and ensure they are re-emitted even when the source file has not changed since the last build?
