-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add clippy to toolstate.toml
#44679
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 to toolstate.toml
#44679
Conversation
cc @rust-lang/dev-tools, any thoughts about this? The tl;dr; here is that you should be able to just change a line in |
src/bootstrap/check.rs
Outdated
|
||
// Don't build tests dynamically, just a pain to work with | ||
cargo.env("RUSTC_NO_PREFER_DYNAMIC", "1"); | ||
// miri tests need to know about the stage sysroot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/miri/clippy?
do we need to still know the sysroot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm +1 on this. We should probably encourage that folks try to get a working patch to fix it at least (even if they then hand it off to someone else to coordinate landing). But the general tooling sounds good and easy to use. |
I'm +1 on adding Clippy to toolstate.toml. I don't think we should enable testing by default at this stage - I'm not confident enough of the workflow here just yet (I'm in favour of taking this super-slowly because I worry about causing issues for compiler devs or of tools getting broken and disabled but not fixed, and I think it is worth getting the workflow right for all tools, rather than rushing to push Clippy forward). |
(Since this confused me, nrc clarified that he's only referring to postponing testing, not building clippy.) |
I would prefer to allow changing the toolstate to testing, if only so we get pinged when it happens and the state is downgraded to building. It is not possible to change the toolstate to broken if it is still building. So there won't be any "overreaction" on the Dev side. That said, I can make the testing pass not run by default, which will mean that even if the state is changed to testing, it'll require explicitly running |
I disabled clippy testing without passing a full path |
|
Just to ensure that we're continuing to take this slowly, can this continue to disable clippy by default? |
Done |
@bors: r+ |
📌 Commit 7d7e7d4 has been approved by |
Add clippy to `toolstate.toml` r? @alexcrichton cc @Manishearth I have no idea how to get clippy working... it needs proc macros, and I think I did everything right (I just did what the cargo step is doing), but it's not working: ``` error: libproc_macro-6210e4b46662ec28.so: cannot open shared object file: No such file or directory --> src/tools/clippy/clippy_lints/src/lib.rs:47:1 | 47 | extern crate serde_derive; | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: libproc_macro-6210e4b46662ec28.so: cannot open shared object file: No such file or directory --> src/tools/clippy/clippy_lints/src/lib.rs:47:1 | 47 | extern crate serde_derive; | ^ ``` It's especially weird since it used to work Anyway. Fixing it can be left for a future PR, this one adds it to CI, but marks it as "broken"
☀️ Test successful - status-appveyor, status-travis |
r? @alexcrichton
cc @Manishearth
I have no idea how to get clippy working... it needs proc macros, and I think I did everything right (I just did what the cargo step is doing), but it's not working:
It's especially weird since it used to work
Anyway. Fixing it can be left for a future PR, this one adds it to CI, but marks it as "broken"