Rust-clippy: force full re-clippy

Created on 1 Apr 2018  Â·  18Comments  Â·  Source: rust-lang/rust-clippy

I build clippy from git sources (4ef7238b3e6b45596a32eb669a07d85d83ff0f1c).
This is re-open of #2498 as @oli-obk suggested.
And actully nothing changes because of #2582 , and why it should?

Sample code:

use std::io;

pub fn map_err(err: io::Error) -> String {
    format!("{}", err)
}
$ cargo clippy
   Compiling foo v0.1.0 (file:///tmp/foo)
warning: this argument is passed by value, but not consumed in the function body
 --> src/lib.rs:3:21
  |
3 | pub fn map_err(err: io::Error) -> String {
  |                     ^^^^^^^^^ help: consider taking a reference instead: `&io::Error`
  |
  = note: #[warn(needless_pass_by_value)] on by default
  = help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.191/index.html#needless_pass_by_value

    Finished dev [unoptimized + debuginfo] target(s) in 0.14 secs
$ cargo clippy
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs

As you use the second run of clippy gives nothing, and cargo clippy --help
have no options to force rerun.

L-bug

Most helpful comment

If the cargo folks agree, perhaps we could have commandline arg in cargo which forces the package to be rebuilt. (cargo check -f / --force or something like that).
I guess the flag then needs to be hooked up in.
https://github.com/rust-lang-nursery/rust-clippy/blob/master/src/main.rs#L103-L111

We would somehow need to make sure it only forces recheck of the crates in the current workspace and not all dependencies as well, not sure what is the best way to do this though.. :/

All 18 comments

I usually work around this by runnning something like touch src/main.rs ; cargo clippy

can you try with clippy 0.0.203? I included a possible fix there

I still have the issue with clippy 0.0.203 :cry:

Also seeing this with v0.0.204

cc @alexcrichton is there any way we can get a mode to cargo check that always rebuilds the toplevel crate (i.e. the root, or if running -p, that crate). Preferably not clobbering artefacts unless they need to be.

@killercup is fixing the same bug that cargo fix has over in https://github.com/rust-lang/cargo/pull/5750, which I'm hopeful will make fixing this much easier.

Memo to self (and promise to clippy maintainers) to actually expose this
somehow to non-cargo consumers!

On Wed, 25 Jul 2018, 07:55 Dale Wijnand, notifications@github.com wrote:

@killercup https://github.com/killercup is fixing the same bug that cargo
fix has over in rust-lang/cargo#5750
https://github.com/rust-lang/cargo/pull/5750, which I'm hopeful will
make fixing this much easier.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rust-clippy/issues/2604#issuecomment-407641897,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOXw4Lf8MmMPJ4yUwEYQs4DVlt7yRfks5uKAhTgaJpZM4TCq2v
.

rust-lang/cargo#5944 was merged, which is a rebase of killercup's work. I'd be open to working on a fix for this, if there is anyone who can provide guidance on what is needed from the clippy side?

If the cargo folks agree, perhaps we could have commandline arg in cargo which forces the package to be rebuilt. (cargo check -f / --force or something like that).
I guess the flag then needs to be hooked up in.
https://github.com/rust-lang-nursery/rust-clippy/blob/master/src/main.rs#L103-L111

We would somehow need to make sure it only forces recheck of the crates in the current workspace and not all dependencies as well, not sure what is the best way to do this though.. :/

Even something as simple as detecting that no work has been done and outputting a warning suggesting the user touch the root file would improve the user experience drastically, I think.

I believe the ideal solution is a diagnostic-caching mechanism, but currently users have no indication that cargo build && cargo clippy is a misuse of Clippy, or that their code may have lint warnings or errors that they're not seeing.

I just submitted rust-lang/cargo#6664 to cargo to force cargo check to rebuild. There may be some additional work needed there, but hopefully that will move this issue forward.

It seems rust-lang/cargo#6664 is close to getting merged. It would be helpful if someone familiar with how clippy integrates with cargo could check in and confirm this would solve the clippy use case.

Yes, but we may need to pass a flag down

Encountered this problem - when i run clippy twice with different parameters, the program didn't get rebuilt, so i got no output.

This is fixed on latest master of cargo for clippy-preview (via rust-lang/cargo#7157). I'll be updating nightly soon. Migrating to clippy-preview is tracked in #3837.

Still an issue for me.

cargo clippy --version
clippy 0.0.212 (4ee12063 2020-02-01)

cargo --version
cargo 1.42.0 (86334295e 2020-01-31)

rustc --version
rustc 1.42.0 (b8cedc004 2020-03-09)

rustup toolchain list
stable-x86_64-pc-windows-msvc (default)

@Livven It was fixed as a nightly-only feature, which has since been removed. We are migrating to a new approach, which should hopefully land soonish via #5363.

@ehuss Thanks for the info, looking forward to it. Seems like it should also fix #5199.

Was this page helpful?
0 / 5 - 0 ratings