force full re-clippy

[davemilter]

I build clippy from git sources (4ef7238).
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.

[matthiaskrgr]

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

[oli-obk]

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

[CyrilCalmels]

I still have the issue with clippy 0.0.203 😢

[baumanj]

Also seeing this with v0.0.204

[Manishearth]

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.

[dwijnand]

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

[killercup]

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, ***@***.***> wrote: @killercup <https://github.com/killercup> is fixing the same bug that cargo fix has over in rust-lang/cargo#5750 <rust-lang/cargo#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 <#2604 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOXw4Lf8MmMPJ4yUwEYQs4DVlt7yRfks5uKAhTgaJpZM4TCq2v> .

[JoshMcguigan]

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?

[matthiaskrgr]

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.. :/

[BatmanAoD]

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.

[JoshMcguigan]

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.

[JoshMcguigan]

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.

[Manishearth]

Yes, but we may need to pass a flag down

[crlf0710]

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