Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running cargo clippy then making changes seems to hide all lints; requires removing target/debug/build #5456

Closed
sollyucko opened this issue Apr 12, 2020 · 4 comments

Comments

@sollyucko
Copy link

sollyucko commented Apr 12, 2020

Running cargo clippy then making changes seems to hide all lints; requires removing target/debug/build.

How to trigger the problem

  1. Create a Cargo project.
  2. Add some code that triggers a Clippy lint.
  3. Run cargo clippy. Make sure this outputs lint messages.
  4. Modify the code, without resolving (all of) the issues. (Even just re-saving the file might work.)
  5. Run cargo clippy.
  6. Modify the code, without resolving (all of) the issues. (Even just re-saving the file might work.)
  7. Run cargo clippy. Problem: no lint messages are displayed.
  8. Run rm -r target/debug/build and/or rm -r target/debug/build (make sure to delete a folder with files in it).
  9. Run cargo clippy. Workaround: the messages are visible again.

Version info

clippy 0.0.212 (23549a8 2020-03-16)
cargo 1.44.0-nightly (7019b3ed3 2020-03-17)
rustc 1.44.0-nightly (f509b26a7 2020-03-18)
Linux ghostwheel 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux
@phansch
Copy link
Member

phansch commented Apr 13, 2020

Hi, thanks for the report! This is a known issue and will eventually be fixed by #3837. You can also run touch src/main.rs to display the lint messages again.

@phansch phansch closed this as completed Apr 13, 2020
@vn971
Copy link
Contributor

vn971 commented Jul 26, 2020

@phansch hi, thanks for the explanation and the work-around suggestion! One week after your comment here though, the referenced issue got an update:

We have decided to not move cargo-clippy into Cargo, but instead provide better integration points so that it is not necessary.
...

With that in mind, should this issue be re-opened? What's the path to solve it?

@flip1995
Copy link
Member

This issue is still tracked in #3837 and we're currently waiting for cargo to stabilize some internals to get the fix to stable. In the meantime you can use cargo clippy -Zunstable-options on nightly, where this should be fixed.

@vn971
Copy link
Contributor

vn971 commented Jul 26, 2020

@flip1995 Thanks for explaining!

memrisync pushed a commit to memri/pod that referenced this issue Nov 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants