Move cargo-clippy into cargo

[Manishearth]

See rust-lang/cargo#6664 (comment) for some context.

Currently cargo clippy is a thin wrapper script around Cargo that invokes cargo check with a RUSTC_WRAPPER: https://github.com/rust-lang/rust-clippy/blob/8dfabdf11c6cdaffd7c6e6552a6ead8d52c49b10/src/main.rs

It does some additional hacks to support the clippy dogfood test and passing down arguments.

We should move this into cargo proper, like rustc: Ideally it's just a copy of cargo check that sets a different rustc executable (temporarily can be done by overriding RUSTC_WRAPPER, but the better solution probably involves modifying config.rustc() https://github.com/rust-lang/cargo/blob/716b02cb4c7b75ce435eb06defa25bc2d725909c/src/cargo/util/config.rs#L194-L215

Steps:

• Add cargo clippy-preview to cargo Cargo clippy cargo#6759
• Make it work with dogfood tests Update dogfood tests to use cargo clippy-preview #4050
• Improve cargo integration, especially with cargo fix call clippy-driver directly rather than as a rustc_wrapper cargo#7006
• add better help Better help support in clippy-driver #4173
• Make cargo-clippy shell out to clippy-preview?
• Perhaps make -Wlintname work as a shortcut for -Wclippy::lintname
• rename and stabilize cargo clippy-preview

[Manishearth]

I think as a first step we should write a very basic cargo clippy-preview (nightly only?) subcommand for cargo that just is a copy of cargo check with rustc_wrapper set. We can also clean it up to make this part of the config.

We can then do the back and forth of testing it with clippy to ensure it works, and eventually rename and ship it. We should probably continue to ship cargo-clippy for a couple releases since in some cases you use a cargo from an older release.

Once we have this there are a bunch of nice changes we can make: e.g. we can modify the argument parsing so that you can just do cargo clippy -Wclippy::foo instead of needing the pesky --.

This also helps integration with cargo fix, since that can now be wholly solved on the cargo side.

[Manishearth]

One implementation issue is that rustup currently does not export a clippy-driver binary, we should change it to do this.

[Manishearth]

This could also be handled by using the current exe path I guess.

[Manishearth]

Filed rust-lang/rustup#1678

I do have concerns as to how this will work for non-rustup users.

[Manishearth]

@yaahallo is looking into implementing this

[Manishearth]

Shouldn't have been closed

[kentfredric]

Where should I file bugs about clippy-preview? rust-clippy or cargo?

Context:

cargo clippy-preview --help

To allow or deny a lint from the command line you can use `cargo clippy --`
with:

    -W --warn OPT       Set lint warnings
    -A --allow OPT      Set lint allowed
    -D --deny OPT       Set lint denied
    -F --forbid OPT     Set lint forbidden

cargo clippy-preview --all-targets -Z unstable-options -- -W clippy::all

error: Found argument '-W' which wasn't expected, or isn't valid in this context

cargo clippy-preview --all-targets -Z unstable-options -W clippy::all

error: Found argument '-W' which wasn't expected, or isn't valid in this context

The actual value passed to -W seems irrelevant.

[Manishearth]

It's not supposed to be used yet, that behavior is expected.

[kentfredric]

It's not supposed to be used yet, that behavior is expected.

I'm aware, I don't use it actively, I've just thrown it into my stack in such a way I can preemptively test it, so I can identify anything that might need to be addressed before it progresses towards some kind of usable thing.

Just trying to be helpful, not annoying :)

[Manishearth]

Yeah, so that stuff is on the list of things to make work, but it's not yet fixed.

I should file some subissues for people to work on, let me know if you're interested in helping!

[Manishearth]

Filed #4172 and #4173

[ehuss]

I think this may have been inadvertently closed (GitHub seems to be a little too aggressive scanning commit messages when pushed). Although, given that, I'm a little uncertain which steps are left to transition to clippy-preview. Should we discuss flipping the switch in 1.39? Exactly which steps should we take from here?

[yaahc]

@ehuss I've been waiting on a review for the change below before proceeding with the last few features for the new clippy.

rust-lang/cargo#7232

[ehuss]

Oh, and also for step 2 of removing cargo-clippy, there are some updates needed in rustbuild to remove it from the distribution (roughly around here), but I can help with that if needed when the time comes.

[Manishearth]

But it may be a good idea to avoid confusion.

I would wait a bit because iirc there are situations where you have an older cargo and a newer toolchain, so we should wait a couple cycles for this.

[U007D]

I'm curious what the plan is for cargo test and cargo run, etc. being invoked with clippy?

For context, I prefer to use clippy like a -Wall/-Weverything (gcc/clang) strict compilation setting (ie. clippy runs on every cargo build/run/test/etc.), as opposed to an occasional "check to see what the linter thinks about all this new code I wrote".

To achieve this, currently I use the RUSTC wrapper technique. With clippy integrated into cargo, will clippy be able to be configured to be invoked on any compilation initiated by cargo?

[Manishearth]

No plan currently, but it should be easy to add once the main stuff is done.

[ehuss]

Update

We have decided to not move cargo-clippy into Cargo, but instead provide better integration points so that it is not necessary. These changes just landed on nightly, and you can test them with:

cargo +nightly clippy -Zunstable-options

The main enhancement here is that clippy will share the cache with cargo check except for workspace members.

Additionally, a new --fix flag was added to automatically apply machine-applicable clippy suggestions.

More details may be found at rust-lang/cargo#8143 and #4612.

[TheBlueMatt]

What does this imply for non-rustup users who wish to use clippy?

[flip1995]

Nothing, AFAICT.

[TheBlueMatt]

To rephrase, does that imply clippy will never (again) be available on non-rustup installs (which seems to have been hinted at as a side-effect earlier in this issue).

[flip1995]

I mean you can always clone the repo and run cargo install --path .. The changes talked about in this issue are only internal changes to Clippy and cargo, that shouldn't be noticable to the user (except that it fixes long standing issues).

What is your current setup now and how do you install Clippy right now?

[TheBlueMatt]

What is your current setup now and how do you install Clippy right now?

apt-get install cargo (+rustc) (cause its easy, always up-to-date within a week or two (on debian testing, at least), and cross-language LTO and even LLVM plugins Just Work (tm) cause its all linked again system LLVM. As for clippy, well, I have to spin up a VM with rustup to use clippy, which is somewhat annoying (afaict - is there some easier way that works - cargo install clippy hasn't worked in a long time).

[Manishearth]

No, there is no easier way for this to work. This is up to the package maintainers to provide.

We recommend the rustup method.

[opeik]

We have decided to not move cargo-clippy into Cargo, but instead provide better integration points so that it is not necessary. These changes just landed on nightly, and you can test them with:

Out of curiosity, is this decision permanent? If so, should this issue stay open?

[Manishearth]

Yeah this can be closed. We got most of the same benefits from the workspace wrapper work.