-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Type safe CLI implementation for clippy-dev #12747
Conversation
r? @Alexendoo rustbot has assigned @Alexendoo. Use |
clippy_dev/Cargo.toml
Outdated
version = "0.0.1" | ||
edition = "2021" | ||
|
||
[dependencies] | ||
aho-corasick = "1.0" | ||
clap = "4.1.4" | ||
clap = { version = "4.1.4", features = ["derive"] } |
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.
IIRC we were using the manual API so that we didn't have to compile syn
& friends to use cargo dev
, are we fine with that trade-off?
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.
This branch:
$ cargo clean
$ time cargo dev
Compiling [...]
Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.14s
Running `target/debug/clippy_dev`
cargo dev 11.40s user 1.96s system 420% cpu 3.173 total
master:
$ cargo clean
$ time cargo dev
Compiling [...]
Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.20s
Running `target/debug/clippy_dev`
cargo dev 7.72s user 1.48s system 412% cpu 2.231 total
So it takes a bit longer to compile, but not significantly longer. I think this trade-off is fine.
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.
but not significantly longer
Well it takes 50% longer. But compiling from a clean build in 11.4s instead of in 7.7s isn't too bad IMO
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.
Maybe some context, why I'm doing this helps here: I'm working on automating the sync and release process using josh instead of subtree. To do this, I'll have to add a few more deps to clippy_dev
anyway, i.e. chrono
, directories
, and xshell
.
So the number of deps will grow anyway and so will the commands. I find the current command definition already bloated, so I wanted to clean up the command generation first, before adding to it.
Here's the PoC commit: #12759
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 don't love it but it's palatable. Is it possible for us to have changes that exist in the clippy repo but not upstream? If we could add a [workspace]
to our root Cargo.toml
that only exists locally that would allow us to be sure the syn
compilation can be shared by clippy itself mitigating the extra time spent here
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.
Sadly this is not possible, without a lot of overhead when doing the sync. One idea might be to add Cargo.toml.local
files and then move our whole dev workflow (including building and testing) to cargo dev
, which would use the .local
files, rather than the Cargo.toml
files that are used in rustc
.
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.
That makes sense, it could also be pretty finicky on syncs if we can't easily modify the rust repo/clippy repo versions directly in the same PR
An idea to keep normal Cargo.toml
s around:
- Move our current root package (cargo-clippy/clippy-driver) into a directory
- Upstream, create a virtual workspace
src/tools/clippy/workspace/Cargo.toml
(unused in the rust repo) - Use a composition filter to map it to be the root
Cargo.toml
in the Clippy repo with the rest of the files mapped as normal
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.
Yeah, with Josh we could do something like this. That's actually a good idea. But first we'd need to move to Josh.
If you want, I can also rebase my Josh work on master
using the non-derive Clap interface and we wait with merging this until we have all the virtual workspace infra in place.
ba2e1c1
to
3497af6
Compare
Use the derive feature of `clap` to generate CLI of clippy-dev. Adding new commands will be easier in the future and we get better compile time checking through exhaustive matching.
Same version as most other crates in rustc are using
3497af6
to
537ab6c
Compare
Spent too long trying to find Merging this now seems fine to me, ideally we can have a local workspace in the future but if we don't it's not a huge deal to duplicate syn sometimes @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
1 similar comment
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request. |
Use the derive feature of
clap
to generate CLI of clippy-dev. Adding new commands will be easier in the future and we get better compile time checking through exhaustive matching.I think I tested everything locally. But I would appreciate if the reviewer could go over it again, so that everything keeps working.
changelog: none