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

Add clippy and fix commands to x.py #56595

Merged
merged 1 commit into from
May 26, 2019
Merged

Conversation

ljedrz
Copy link
Contributor

@ljedrz ljedrz commented Dec 7, 2018

Since they are kind of similar in nature, I have used the same approach as for cargo check. At least some of the boilerplate could probably be shared, but I'd prefer to gather some feedback before I decide to merge them more aggressively.

This works reasonably well for clippy; with -A clippy::all and some extra #![feature(rustc_private)]s almost the whole codebase can be processed. There are some concerns, though:

  • unlike check, in order to be able to traverse all the crates, some of them need to be marked with the #![feature(rustc_private)] attribute
  • -W clippy::all breaks on any error. Is there a way to produce errors but not have them break the progress?
  • I'm not sure how to redirect the errors in a way that would show colors; for now I was able to de-jsonize and print them (something not needed for check)

cargo fix is much more stubborn; it refuses to acknowledge crates like core and std, so it doesn't progress much at all.

Since this is a bit more tricky than I have envisioned, I need some guidance:

  • is this the right approach or am I doing something very wrong ^^?
  • why are the extra rustc_private features necessary? I was hoping for the same treatment as check
  • are changes in clippy and cargo fix needed e.g. in order to produce errors in the same manner as check or did I miss something?
  • do we need this level of file granularity (e.g. for futureproofing) or can check, clippy and fix files be condensed?

Hopes-to-fix: #53896

Cc @alexcrichton, @zackmdavis

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 7, 2018
@ljedrz ljedrz mentioned this pull request Dec 7, 2018
@bors
Copy link
Contributor

bors commented Dec 8, 2018

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

@nikomatsakis
Copy link
Contributor

r? @alexcrichton

kennytm added a commit to kennytm/rust that referenced this pull request Dec 12, 2018
bootstrap: fix edition

A byproduct of work on rust-lang#56595; done with `cargo fix --edition`.
kennytm added a commit to kennytm/rust that referenced this pull request Dec 13, 2018
bootstrap: fix edition

A byproduct of work on rust-lang#56595; done with `cargo fix --edition`.
kennytm added a commit to kennytm/rust that referenced this pull request Dec 14, 2018
bootstrap: fix edition

A byproduct of work on rust-lang#56595; done with `cargo fix --edition`.
kennytm added a commit to kennytm/rust that referenced this pull request Dec 14, 2018
bootstrap: fix edition

A byproduct of work on rust-lang#56595; done with `cargo fix --edition`.
@alexcrichton
Copy link
Member

Thanks for the PR! I'm somewhat hesitant to merge this in though because it seems like it's presumably duplicating a lot of code already there for other aspects of rustbuild. Rustbuild already suffers from a good deal of duplication, so I think I'd personally prefer if we could try to explore strategies of deduplication before merging these in

@mark-i-m
Copy link
Member

I would kind of like to merge this actually. It would be a big step towards moving the compiler to edition 2018.

@ljedrz
Copy link
Contributor Author

ljedrz commented Dec 15, 2018

@alexcrichton there is definitely room for improvement in terms of deduplication, that's one of the reasons for the WIP; I just wanted to make sure the general approach was fine before squeezing the code a bit more.

I'll rebase and deduplicate the code shortly.

@ljedrz ljedrz changed the title [WIP] Add clippy and fix commands to x.py Add clippy and fix commands to x.py Dec 15, 2018
@ljedrz
Copy link
Contributor Author

ljedrz commented Dec 15, 2018

@alexcrichton I updated the commit - the new commands are now integrated into check.rs.

bors added a commit that referenced this pull request Dec 15, 2018
bootstrap: fix edition

A byproduct of work on #56595; done with `cargo fix --edition`.
@bors
Copy link
Contributor

bors commented Dec 16, 2018

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

@ljedrz
Copy link
Contributor Author

ljedrz commented Dec 16, 2018

Rebased.

@@ -23,6 +23,22 @@ pub struct Std {
pub target: Interned<String>,
}

fn args(kind: Kind) -> Vec<String> {
match kind {
Kind::Clippy => vec!["--".to_owned(), "-W".to_owned(), "clippy::all".to_owned()],
Copy link
Contributor

Choose a reason for hiding this comment

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

-W clippy::all breaks on any error. Is there a way to produce errors but not have them break the progress?

--cap-lints warn should work.

Copy link
Contributor Author

@ljedrz ljedrz Dec 17, 2018

Choose a reason for hiding this comment

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

I managed to pass it into clippy arguments, but it doesn't seem to be enough 🤔.

@sinkuu
Copy link
Contributor

sinkuu commented Dec 16, 2018

unlike check, in order to be able to traverse all the crates, some of them need to be marked with the #![feature(rustc_private)] attribute

You can make Builder::cargo to add RUSTFLAGS="-Zforce-unstable-if-unmarked" instead of RUSTC_FORCE_UNSTABLE=1 when cmd == "clippy". Bootstrap's rustc shim adds the flag when RUSTC_FORCE_UNSTABLE is found, but cargo clippy invokes its own rustc driver.

I'm not sure how to redirect the errors in a way that would show colors; for now I was able to de-jsonize and print them (something not needed for check)

This is also due to rustc shim. It removes --message-format json from args passed to rustc, so rustc normally prints colored errors to stderr.

@ljedrz
Copy link
Contributor Author

ljedrz commented Dec 16, 2018

Thanks for the suggestions @sinkuu! I'll apply them soon.

Edit: I added RUSTFLAGS="-Zforce-unstable-if-unmarked" for clippy and fix, but I don't know how I can override --message-format json; any ideas?

@ljedrz ljedrz force-pushed the x_py_clippy_fix branch 2 times, most recently from 5176bb1 to 0820b48 Compare December 17, 2018 12:48
@oli-obk
Copy link
Contributor

oli-obk commented Apr 23, 2019

@ljedrz you can now have the colors in the rendered field of json ouptut via --json-rendered=termcolor

@ljedrz
Copy link
Contributor Author

ljedrz commented Apr 23, 2019

Thanks! I'm currently traveling, but I'll get back to this shortly.

@ljedrz
Copy link
Contributor Author

ljedrz commented Apr 23, 2019

With the addition of the new flag we now have available thanks to @oli-obk, I am now able to run e.g. ./x.py clippy src/librustc_driver and see nice output.

This option doesn't seem to be available to fix, though, so now I'm wondering if it should also be added to it or if I should omit that parameter from that command altogether for now.

@mark-i-m
Copy link
Member

It sounds like a nice addition, but perhaps in a followup PR?

@oli-obk oli-obk added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 24, 2019
@ljedrz
Copy link
Contributor Author

ljedrz commented Apr 24, 2019

Done; at this point the fix support is limited, but clippy appears to be operational.

@Centril
Copy link
Contributor

Centril commented Apr 25, 2019

I would kind of like to merge this actually. It would be a big step towards moving the compiler to edition 2018.

The entirety of the repo (+ relevant submodules) has been moved to 2018 so this PR is no longer needed for that.

(but it is still nice for other things...)

@Centril
Copy link
Contributor

Centril commented May 18, 2019

r? @oli-obk

src/bootstrap/builder.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented May 24, 2019

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

@ljedrz ljedrz force-pushed the x_py_clippy_fix branch from ecb42b8 to 2f3533b Compare May 25, 2019 13:32
@@ -898,6 +902,11 @@ impl<'a> Builder<'a> {
extra_args.push_str(&s);
}

if cmd == "clippy" {
extra_args.push_str("-Zforce-unstable-if-unmarked -Zunstable-options \
Copy link
Contributor

Choose a reason for hiding this comment

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

have you tested that this prevents the rebuilds? I would have assumed this to still cause build thrashing. If this works, then I'm happy with it, if not, you should be able to add them in the args function you created below by putting them after a -- argument

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just checked it - there are no rebuilds. The only thing is that after throwing its warnings (a lot of stuff found in libcore) ./x.py clippy is complaining that it can't find crate for std and I no longer remember if this was an acceptable step forward or not ^^. I remember having trouble making it respect the build order.

Copy link
Contributor

Choose a reason for hiding this comment

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

While not great, we can solve this in follow-ups. I think this may happen whenever one tries to run clippy on a target without libstd, so it's likely that it's a clippy issue.

@oli-obk
Copy link
Contributor

oli-obk commented May 25, 2019

@bors r+

@bors
Copy link
Contributor

bors commented May 25, 2019

📌 Commit 2f3533b has been approved by oli-obk

@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 May 25, 2019
@bors
Copy link
Contributor

bors commented May 25, 2019

⌛ Testing commit 2f3533b with merge 483567e...

bors added a commit that referenced this pull request May 25, 2019
Add clippy and fix commands to x.py

Since they are kind of similar in nature, I have used the same approach as for `cargo check`. At least some of the boilerplate could probably be shared, but I'd prefer to gather some feedback before I decide to merge them more aggressively.

This works reasonably well for `clippy`; with `-A clippy::all` and some extra `#![feature(rustc_private)]`s almost the whole codebase can be processed. There are some concerns, though:
- unlike `check`, in order to be able to traverse all the crates, some of them need to be marked with the `#![feature(rustc_private)]` attribute
- `-W clippy::all` breaks on any error. Is there a way to produce errors but not have them break the progress?
- I'm not sure how to redirect the errors in a way that would show colors; for now I was able to de-jsonize and print them (something not needed for `check`)

`cargo fix` is much more stubborn; it refuses to acknowledge crates like `core` and `std`, so it doesn't progress much at all.

Since this is a bit more tricky than I have envisioned, I need some guidance:
- is this the right approach or am I doing something very wrong ^^?
- why are the extra `rustc_private` features necessary? I was hoping for the same treatment as `check`
- are changes in `clippy` and `cargo fix` needed e.g. in order to produce errors in the same manner as `check` or did I miss something?
- do we need this level of file granularity (e.g. for futureproofing) or can `check`, `clippy` and `fix` files be condensed?

Hopes-to-fix: #53896

Cc @alexcrichton, @zackmdavis
@bors
Copy link
Contributor

bors commented May 26, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: oli-obk
Pushing 483567e to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 26, 2019
@bors bors merged commit 2f3533b into rust-lang:master May 26, 2019
@ljedrz ljedrz deleted the x_py_clippy_fix branch May 26, 2019 02:13
djrenren pushed a commit to djrenren/compiletest that referenced this pull request Aug 26, 2019
Emit ansi color codes in the `rendered` field of json diagnostics

cc @ljedrz

Implemented for rust-lang/rust#56595 (comment) (x.py clippy)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

x.py fix