Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo clippy #6759

Merged
merged 13 commits into from
Apr 1, 2019
Merged

Cargo clippy #6759

merged 13 commits into from
Apr 1, 2019

Conversation

yaahc
Copy link
Member

@yaahc yaahc commented Mar 17, 2019

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 17, 2019
src/bin/cargo/commands/clippy.rs Show resolved Hide resolved
src/cargo/util/config.rs Outdated Show resolved Hide resolved
src/cargo/util/config.rs Outdated Show resolved Hide resolved
src/cargo/util/paths.rs Outdated Show resolved Hide resolved
@Manishearth
Copy link
Member

For some background, this is the first major step for implementing cargo-clippy in Cargo, which is why the command is called clippy-preview. Doing it step by step so we can ensure the clippy repo can still CI with this.

@alexcrichton
Copy link
Member

Thanks for the PR @yaahallo! Scanning over rust-lang/rust-clippy#3837 and the implementation here, it's not entirely clear to me what the transition plan is here, although it looks like cargo clippy-preview is being added here to eventually replace cargo clippy itself, but the thinking is that clippy-preview can be used in the meantime?

If so I agree with @Manishearth that we'll want this command to be nightly-only for now, which basically means we should probably just require that -Z unstable-options is passed as well to enable the command.

Would it be possible to take a cargo-fix-style approach though to avoid adding too much special code for clippy in a few places? Ideally all the clippy-specific logic would be in one or two central spots

@Manishearth
Copy link
Member

@alexcrichton the transition plan is that:

  • clippy-preview is implemented (this PR). nobody aside clippy devs use it, while experimenting with upgrading clippy CI for this
  • clippy CI is upgraded to run all tests with cargo clippy-preview
  • cargo clippy-preview is renamed to cargo clippy, and made stable. Clippy still ships a cargo-clippy binary so that people using fallback cargos are not affected during the transition.
  • Clippy's cargo-clippy binary is removed after a release cycle.
  • Further improvements to cargo clippy may be made

So yeah, making it nightly only makes sense. Naming it "preview" lets us experiment without causing any issues to real users of cargo clippy.

Would it be possible to take a cargo-fix-style approach though to avoid adding too much special code for clippy in a few places?

As far as I can tell this is the cargo-fix-style approach, cargo-clippy is an extremely thin wrapper around cargo check and will be implemented as such here. The main departures from cargo check will be:

  • Runs clippy-driver on toplevel crates instead of rustc (implemented here)
    • In the future may be improved to do this for all local workspace crates or something. Cargo fix needs this too. (not implemented here)
  • Different help text (implemented here)
  • May directly accept -W clippy::foo-style arguments. (not implemented yet)
  • Eventually will integrate with cargo fix (not implemented yet, but easier to implement once cargo clippy is part of cargo)

@yaahc
Copy link
Member Author

yaahc commented Mar 18, 2019

I'll go ahead and add the -Z unstable-options requirement right now.

@Manishearth
Copy link
Member

A future simplification that can be made is to stop using the rustc-wrapper functionality and instead directly call it as a drop-in for rustc. Note that doing this would require tweaking cargo to know which crates to run clippy on (currently clippy-driver makes this decision). This makes it easier to support things like running clippy on all local workspace crates.

src/bin/cargo/commands/clippy.rs Outdated Show resolved Hide resolved
src/bin/cargo/commands/clippy.rs Outdated Show resolved Hide resolved
src/cargo/util/config.rs Outdated Show resolved Hide resolved
src/cargo/util/config.rs Outdated Show resolved Hide resolved
@ehuss
Copy link
Contributor

ehuss commented Mar 18, 2019

avoid adding too much special code for clippy in a few places

I agree that it feels like there is too much special code. With this, there are now 4 wrappers (BuildConfig::cargo_as_rustc_wrapper, Config::clippy_override, RUSTC_WRAPPER, and RUSTC). It would be nice if it was simplified and more generalized (and be easy to use clippy with cargo-fix), but that may not be easy.

@Manishearth
Copy link
Member

How complex would it be to merge the wrappers? If it's pretty complex I'd prefer to land this so we can make further progress on the clippy side, and then in tandem improve the wrapper situation.

We plan to make cargo clippy work with cargo fix as part of these changes so I suspect the wrappers will get merged eventually anyway.

src/cargo/util/config.rs Outdated Show resolved Hide resolved
@alexcrichton
Copy link
Member

We curently already have cargo::util::rustc::Rustc as an abstraction for RUSTC and RUSTC_WRAPPER. I think Config::clippy_override is probably not what we want because it's such a global decision for a local property (aka only during cargo clippy's own build are we using clippy as a wrapper).

We can probably fix this duplication and scattering easily with:

  • Rename Config::rustc to something like Config::load_global_rustc
  • Add #[derive(Clone)] to Rustc
  • Add Rustc field to BuildConfig
  • Remove cargo-fix specific logic in compiler/compilation.rs
  • Update Rustc to have the various functionality necessary, adding hooks for cargo clippy as well as cargo fix)

@yaahc
Copy link
Member Author

yaahc commented Mar 19, 2019

Rustc has a cache: Mutex<Cache>, which prevents us from deriving Clone, should I wrap this in Rc/Arc?

@alexcrichton
Copy link
Member

I don't recall the purpose of the mutex offhand but I would presume that adding Arc would be fine

@yaahc
Copy link
Member Author

yaahc commented Mar 20, 2019

I'm a bit confused on what the relationship between BuildConfig and Config::load_global_rustc is supposed to be. Did you intend to say to add the Rustc field to Config rather than BuildConfig?

Also BuildContext has a Rustc member

@alexcrichton
Copy link
Member

BuildConfig is sort of a one-shot configuration just for one build, while Config is intended for long-term usage across possibly multiple commands. I'm thinking that the Rustc definition, which is currently loaded from Config, would instead be loaded from BuildConfig. That way commands like fix/clippy would configure BuildConfig appropriately, and the backend would load the compiler from that field instead of Config which doesn't have the fix/clippy-specific modifications

@alexcrichton
Copy link
Member

Also heh I didn't realize it was already there! In that case we should just rename Config::rustc and reroute existing users to build_config.rustc

@@ -141,8 +141,8 @@ impl Rustc {
self.cache.lock().unwrap().cached_success(cmd)
}

pub fn push_wrapper(&mut self, wrapper: RustcWrapper) {
self.wrapper = Some(wrapper);
pub fn push_wrapper<T: Into<Option<RustcWrapper>>>(&mut self, wrapper: T) {
Copy link
Member Author

@yaahc yaahc Mar 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could in theory call push_wrapper(None) with this.... not sure if anybody ever will. If someone ever does though I want to be notified! it would amuse me immensely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if instead of push_wrapper and such, we could do something like this?

pub fn set_wrapper(&mut self, wrapper: ProcessBuilder) {
    assert!(self.wrapper.is_none());
    self.wrapper = Some(wrapper);
}

That way we don't have to duplicate args/env/etc, and I think there's only currently one wrapper so it's fine to avoid the term "push" because we're not adding more than one

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, additionally, multiple wrappers wouldn't work anyway, since we can't pass more than one wrapper down as the first argument (yet)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assert wont work thanks to the test fix::does_not_crash_with_rustc_wrapper which is expected to replace an already defined wrapper.

@yaahc
Copy link
Member Author

yaahc commented Mar 21, 2019

also this is totally broken atm. all the fix:: and build::rustc_wrapper.* tests are broken now

I have to take a break from working on this until tonight or tomorrow though.

@alexcrichton
Copy link
Member

I think this is looking pretty good though! If you need some help with tests and such just let us know!

@bors
Copy link
Collaborator

bors commented Mar 24, 2019

☔ The latest upstream changes (presumably #6781) made this pull request unmergeable. Please resolve the merge conflicts.

Now the fields are just all represented as `rustc_wrapper` which
internally contains all process configuration that's later passed down
to `Rustc` as necessary.
@alexcrichton
Copy link
Member

Ok I pushed a follow up commit with some further refactorings, and I think this is good to go. Thanks @yaahallo!

@bors: r+

@bors
Copy link
Collaborator

bors commented Apr 1, 2019

📌 Commit 842da62 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 1, 2019
@bors
Copy link
Collaborator

bors commented Apr 1, 2019

⌛ Testing commit 842da62 with merge 025b01e...

bors added a commit that referenced this pull request Apr 1, 2019
@yaahc
Copy link
Member Author

yaahc commented Apr 1, 2019

My pleasure :D @alexcrichton

@bors
Copy link
Collaborator

bors commented Apr 1, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 025b01e to master...

@bors bors merged commit 842da62 into rust-lang:master Apr 1, 2019
Centril added a commit to Centril/rust that referenced this pull request Apr 5, 2019
Update cargo

20 commits in
63231f438a2b5b84ccf319a5de22343ee0316323..6f3e9c367abb497c64f360c3839dab5e74928d5c
2019-03-27 12:26:45 +0000 to 2019-04-04 14:11:33 +0000
- Fix Init for Fossil SCM project (rust-lang/cargo#6792)
- Fix member_manifest_version_error accessing the network (rust-lang/cargo#6799)
- Don't include email if it is empty (rust-lang/cargo#6802)
- Fix unused import warning (rust-lang/cargo#6807)
- Add some help and documentation for unstable flags (rust-lang/cargo#6791)
- Allow `cargo doc --open` with multiple packages (rust-lang/cargo#6803)
- Allow `cargo install --path P` to load config from P (rust-lang/cargo#6804)
- Add more suggestions on how to deal with excluding a package from a workspace (rust-lang/cargo#6805)
- Warn on version req with metadata (rust-lang/cargo#6806)
- cargo install: Be more restrictive about cli flags (rust-lang/cargo#6801)
- Support force-pushed repos with git-fetch-with-cli (rust-lang/cargo#6800)
- Cargo clippy (rust-lang/cargo#6759)
- Don't include metadata in wasm binary examples (rust-lang/cargo#6812)
- Update glossary for `feature` (rust-lang/cargo#6809)
- Include proc-macros in `build-override` (rust-lang/cargo#6811)
- Resolver: A dep is equivalent to one of the things it can resolve to (rust-lang/cargo#6776)
- Add some docs for `Downloads` (rust-lang/cargo#6815)
- Resolve: Be less strict while offline (rust-lang/cargo#6814)
- Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)
- Fix doc link (rust-lang/cargo#6820)

<br>

I specifically care about "Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)" to unblock rust-lang#59076.

Mentioning @ehuss.
bors added a commit to rust-lang/rust that referenced this pull request Apr 5, 2019
Update cargo

20 commits in
63231f438a2b5b84ccf319a5de22343ee0316323..6f3e9c367abb497c64f360c3839dab5e74928d5c
2019-03-27 12:26:45 +0000 to 2019-04-04 14:11:33 +0000
- Fix Init for Fossil SCM project (rust-lang/cargo#6792)
- Fix member_manifest_version_error accessing the network (rust-lang/cargo#6799)
- Don't include email if it is empty (rust-lang/cargo#6802)
- Fix unused import warning (rust-lang/cargo#6807)
- Add some help and documentation for unstable flags (rust-lang/cargo#6791)
- Allow `cargo doc --open` with multiple packages (rust-lang/cargo#6803)
- Allow `cargo install --path P` to load config from P (rust-lang/cargo#6804)
- Add more suggestions on how to deal with excluding a package from a workspace (rust-lang/cargo#6805)
- Warn on version req with metadata (rust-lang/cargo#6806)
- cargo install: Be more restrictive about cli flags (rust-lang/cargo#6801)
- Support force-pushed repos with git-fetch-with-cli (rust-lang/cargo#6800)
- Cargo clippy (rust-lang/cargo#6759)
- Don't include metadata in wasm binary examples (rust-lang/cargo#6812)
- Update glossary for `feature` (rust-lang/cargo#6809)
- Include proc-macros in `build-override` (rust-lang/cargo#6811)
- Resolver: A dep is equivalent to one of the things it can resolve to (rust-lang/cargo#6776)
- Add some docs for `Downloads` (rust-lang/cargo#6815)
- Resolve: Be less strict while offline (rust-lang/cargo#6814)
- Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)
- Fix doc link (rust-lang/cargo#6820)

<br>

I specifically care about "Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)" to unblock #59076.

Mentioning @ehuss.
@ehuss ehuss mentioned this pull request Jun 22, 2019
bors added a commit that referenced this pull request Jun 22, 2019
Update some fix comments.

- Primary handling changed in #5824.
- cargo_as_rustc_wrapper changed in #6759.
@ehuss ehuss added this to the 1.35.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move cargo-clippy into cargo
6 participants