Rust-clippy: cargo clippy does not show the warnings if executed twice

[malbarbo]

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]

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]

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]

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]

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]

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

[crumblingstatue]

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]

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]

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]

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

[mcarton]

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]

Looks like a bug in cargo check then.

Opened https://github.com/rust-lang/cargo/issues/3624

[PhilipDaniels]

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]

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

[sesam]

@KetkiT Like this:

1. (On windows? start a bash command prompt first.)
2. First do cargo clean etc to ensure you get it all. Or touch the main .rs files or something. (What this ticket is about...)
3. 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]

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]

Why is this issue closed? Its still a problem.

[flip1995]

See #4612

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

[samwightt]

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

[flip1995]

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

[therealprof]

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]

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]

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]

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]

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]

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]

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.