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

cargo clippy does not show the warnings if executed twice #1495

Closed
malbarbo opened this issue Jan 30, 2017 · 27 comments · Fixed by #2582
Closed

cargo clippy does not show the warnings if executed twice #1495

malbarbo opened this issue Jan 30, 2017 · 27 comments · Fixed by #2582
Labels
C-enhancement

Comments

@malbarbo
Copy link

@malbarbo malbarbo commented Jan 30, 2017

cargo new x && cd x
echo 'pub fn f() { println!("{}", *&10) }' > src/lib.rs
cargo clippy # show the warning deref_addrof
cargo clippy # do not show the warning

I would expect that the warnings to be shown again... If this is a feature, I think something must be write in the docs.

Note that adding a binary and running cargo clippy again does not show the warning in lib:

echo 'fn main() { println!("{}", *&10) }' > src/main.rs
cargo clippy # show one warning in main.rs but not in lib.rs
@mcarton
Copy link
Member

@mcarton mcarton commented Jan 30, 2017

The first one is a feature of rustc itself: when something has been compiled, it won't be recompiled (hence clippy won't see it) until it is modified.

And for the note: If you add a binary to a library crate you also need to update the Cargo.toml file to reflect that. Then Clippy will know about it.

@malbarbo
Copy link
Author

@malbarbo malbarbo commented Jan 30, 2017

The first one is a feature of rustc itself: when something has been compiled, it won't be recompiled (hence clippy won't see it) until it is modified.

How about adding this information in the docs?

And for the note: If you add a binary to a library crate you also need to update the Cargo.toml file to reflect that. Then Clippy will know about it.

I thinking that adding src/main.rs or any file in src/bin does not requires changing Cargo.toml. Try the commands in the first message. See http://doc.crates.io/manifest.html#the-project-layout

@mcarton
Copy link
Member

@mcarton mcarton commented Jan 30, 2017

How about adding this information in the docs?

Sure!

I thinking that adding src/main.rs or any file in src/bin does not requires changing Cargo.toml. Try the commands in the first message. See http://doc.crates.io/manifest.html#the-project-layout

You still need a [lib] and a [[bin]] right? I have some doubts now though, is the file compiled with cargo build? (cargo clippy really is just a wrapper around cargo build)

@malbarbo
Copy link
Author

@malbarbo malbarbo commented Jan 30, 2017

You still need a [lib] and a [[bin]] right? I have some doubts now though, is the file compiled with cargo build? (cargo clippy really is just a wrapper around cargo build)

You do not need extra sections. The file is compiled with cargo build, you can try it yourself.

@llogiq
Copy link
Contributor

@llogiq llogiq commented Jan 31, 2017

If something is called main.rs or is in a src/bin subdirectory, cargo will compile it as binary by default IIRC.

@crumblingstatue
Copy link

@crumblingstatue crumblingstatue commented Jan 31, 2017

The new built-in cargo check command now always shows the warnings, regardless of how many times you run it. Would cargo clippy also have to be a built-in cargo command in order to be able to do that?

@oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jan 31, 2017

I think we could simply ensure that the build doesn't go through, then it needs to rebuild. But that might break once we get incremental compilation

@mcarton
Copy link
Member

@mcarton mcarton commented Jan 31, 2017

The new built-in cargo check command now always shows the warnings

How new is that?

% cargo check
   Compiling zpeifnzepifn v0.1.0 (file:///tmp/zpeifnzepifn)
warning: function is never used: `it_works`, #[warn(dead_code)] on by default
 --> src/lib.rs:1:1
  |
1 |   fn it_works() {
  |  _^ starting here...
2 | |     let a = 32;
3 | | }
  | |_^ ...ending here

warning: unused variable: `a`, #[warn(unused_variables)] on by default
 --> src/lib.rs:2:9
  |
2 |     let a = 32;
  |         ^

    Finished dev [unoptimized + debuginfo] target(s) in 0.6 secs
% cargo check
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
% cargo check
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
% cargo -V
cargo 0.17.0-nightly (67e4ef1 2017-01-25)

@crumblingstatue
Copy link

@crumblingstatue crumblingstatue commented Jan 31, 2017

@mcarton
Weird. The warnings are always reported on a bin crate, but not on a lib crate.

@mcarton
Copy link
Member

@mcarton mcarton commented Jan 31, 2017

Looks like a bug in cargo check then.
Otherwise we might just be able to use whatever sorcery cargo check uses to rewarn every time.

@crumblingstatue
Copy link

@crumblingstatue crumblingstatue commented Jan 31, 2017

Looks like a bug in cargo check then.

Opened rust-lang/cargo#3624

@mcarton mcarton added the C-enhancement label Feb 5, 2017
@PhilipDaniels
Copy link

@PhilipDaniels PhilipDaniels commented Aug 29, 2017

New Rust user here. I would like to second the initial comment of @malbarbo that running cargo clippy twice should show the warnings the second time. It is really confusing.

Also, running cargo check multiple times does not show the warnings for me (I am working on an EXE). I have to do a cargo clean to get the warnings to appear, which means recompiling all the crates too.

I think partly the problem is that the docs do not explain how/when clippy works. Is this a compiler step or something, or is it a binary that is just run over the source code and outputs warnings?

I am going to open another issue about improving the docs.

@KetkiT
Copy link

@KetkiT KetkiT commented May 3, 2018

How to write warnings produced by cargo clippy in a file ?

@sesam
Copy link

@sesam sesam commented Jan 20, 2019

@KetkiT Like this:
0. (On windows? start a bash command prompt first.)

  1. First do cargo clean etc to ensure you get it all. Or touch the main .rs files or something. (What this ticket is about...)
  2. Use cargo-clippy >file.txt 2>&1 (what I came here to find, and now shares if you and I are not alone).

Also please note this issue is closed and is not a support forum :).

@olalonde
Copy link

@olalonde olalonde commented Apr 8, 2020

FWIW I just lost 30 minutes debugging this "feature" thinking there was a problem with my setup. It makes cargo clippy impossible to use in vim (coc-rust-analyzer cargo command)...

@dessalines
Copy link

@dessalines dessalines commented Apr 21, 2020

Why is this issue closed? Its still a problem.

@flip1995
Copy link
Member

@flip1995 flip1995 commented Apr 21, 2020

See #4612

This is now fixed in nightly, when running with cargo clippy -Z unstable-options

@samwightt
Copy link

@samwightt samwightt commented Jun 9, 2020

This should not be closed, it's still an issue.

@flip1995
Copy link
Member

@flip1995 flip1995 commented Jun 9, 2020

This is tracked in #4612 and is fixed on nightly, when executed with cargo clippy -Z unstable-options

@therealprof
Copy link

@therealprof therealprof commented Jun 12, 2020

This is tracked in #4612 and is fixed on nightly, when executed with cargo clippy -Z unstable-options

Interesting but relevant how? I consider an important bugfix like this to be landed when it is available in stable.

NB: Regardless of this this option, another workaround would be to simply use a different compiler for clippy.

@flip1995
Copy link
Member

@flip1995 flip1995 commented Jun 12, 2020

Interesting but relevant how?

No need to keep 2 issues open for the same bug.

when it is available in stable.

This depends on cargo stabilizing internals, not Clippy, so we have little influence on this. Cross-tool fixes are not that trivial.

another workaround would be to simply use a different compiler for clippy

I don't see the point in implementing a workaround for a fixed bug.

@therealprof
Copy link

@therealprof therealprof commented Jun 12, 2020

I don't see the point in implementing a workaround for a fixed bug.

It's a usage workaround, not something that needs to be implemented. For a lot of projects using a different compiler to run clippy is a lot cheaper/quicker than the suggested cargo clean and way more comfortable than having to use a nightly build with an unstable option.

@flip1995
Copy link
Member

@flip1995 flip1995 commented Jun 12, 2020

Hm? What exactly do you mean by "different compilers"? This is a problem with the caching cargo does. cargo clippy is equivalent to cargo check, except for more lints.

@therealprof
Copy link

@therealprof therealprof commented Jun 12, 2020

The problem is that IDEs/editors will automatically run cargo check or equivalent and thus cargo clippy has nothing to do because it's all up-to-date. Using a different compiler prevents that.

# cargo check
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
# cargo clippy
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
# cargo +nightly clippy
...
warning: 2 warnings emitted

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

That's what I'm doing all the time because essentially it's much faster than a clean build. It's also faster than running clippy in release mode which would also work.

# cargo clippy --release
...
warning: 2 warnings emitted

    Finished release [optimized] target(s) in 1m 15s

@flip1995
Copy link
Member

@flip1995 flip1995 commented Jun 12, 2020

That wouldn't solve the problem, since executing cargo clippy twice would still have no output the second time. Again, the problem is solved, we're just waiting on cargo to stabilize something.

@therealprof
Copy link

@therealprof therealprof commented Jun 12, 2020

It does solve work around the problem because the code is modified in the meantime. Again, this is about the tools doing the cargo check invocation in the background, e.g. on save, so when you trigger clippy or manually run it it will say: Not modified, nothing to do here.

As the name workaound implies, it's a working around a deficiency which is described in this issue.

@nyanpasu64
Copy link

@nyanpasu64 nyanpasu64 commented Jan 21, 2021

In my project, I found that (with the latest cargo 1.49.0 stable) both cargo check or cargo clippy will cache a set of warnings (larger in the case of cargo clippy) which will appear in all future runs of either command, until the code is modified and either command is run again. This behavior seems bizzare to me.

EDIT: I think this is already documented at #4612 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.