search

arcnmx / cargo-clippy

cargo clippy
MIT License
68 stars 11 forks source link

Cannot run `cargo clippy` against project with lib and binary #21

Closed posborne closed 8 years ago

posborne commented 8 years ago

Here's a couple of projects with this form:

When trying to run, I get the following:

$ cargo clippy          
error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing e.g. `--lib` or `--bin NAME` to specify a single target
error: third party subcommand `cargo-clippy` exited unsuccessfully

To learn more, run the command again with --verbose.

$ cargo clippy --lib
error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing e.g. `--lib` or `--bin NAME` to specify a single target
error: third party subcommand `cargo-clippy` exited unsuccessfully

To learn more, run the command again with --verbose.

With cargo-check, I am able to pass the appropriate flag to the compiler to point it at a specific binary or the library as follows, but this does not seem to work for cargo-clippy:

$ cargo check      
error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing e.g. `--lib` or `--bin NAME` to specify a single target
error: third party subcommand `cargo-check` exited unsuccessfully

To learn more, run the command again with --verbose.

$ cargo check --lib
   Compiling gpio-utils v0.1.0 (file:///home/posborne/Projects/rust-playground/gpio-utils)
posborne commented 8 years ago

Interesting, this works... The fix then is easy, but I'm a bit baffled by why cargo check works then...

$ cargo-clippy ignored --lib
...
posborne commented 8 years ago

I should add...

$ cargo --version
cargo 0.11.0-nightly (867627c 2016-04-21)
arcnmx commented 8 years ago

Note the CI failure in #22, cargo seems to invoke subcommands using cargo-clippy clippy ARG1 ARG2 etc. argv[0] would be the binary name/path, argv[1] would be clippy... So it does skip(2).

cargo clippy --lib works fine here on cargo 0.11.0-nightly (31e7d5a 2016-04-17). And considering the CI failed on cargo 0.11.0-nightly (867627c 2016-04-21) that still seems to be the case... Does it somehow depend on the OS? I'm on x86_64 Linux.

For the record, I think this behaviour is very silly and wrong... It doesn't make sense to pass the subcommand as the first argument, and git subcommand doesn't behave like that... It might be a cargo bug then?

posborne commented 8 years ago

Yeah, something is weird on my machine I guess. I am on x86_64 and apparently using the same version of cargo as CI. I am using the the new rustup (https://github.com/rust-lang-nursery/rustup.rs) and wondering if that could somehow impact things. It is odd that things work with cargo check which has very similar logic.

Looking at cargo, It does appear that the args passed to the subcommand would include the name of the subcommand (agreed that this behavior seems less than ideal but it would cause problems to change as well).

CC @alexcrichton

alexcrichton commented 8 years ago

Yeah that was proposed in https://github.com/rust-lang/cargo/pull/2220 but it's unfortunately backwards incompatible at this point.

posborne commented 8 years ago

Ok, so the issue appears to be with the version of clippy currently on crates.io. I'll update the PR to just have the unit test additions.

This bug then becomes the following: