-
Notifications
You must be signed in to change notification settings - Fork 2.7k
feat: Add custom completer for completing cargo build --packge <TAB>
#14553
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
base: master
Are you sure you want to change the base?
Conversation
|
r? @weihanglo rustbot has assigned @weihanglo. Use |
|
r? @epage |
src/cargo/util/command_prelude.rs
Outdated
| Ok(targets) | ||
| } | ||
|
|
||
| fn get_package_candidates() -> Vec<clap_complete::CompletionCandidate> { |
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.
| fn get_package_candidates() -> Vec<clap_complete::CompletionCandidate> { | |
| fn get_ws_member_candidates() -> Vec<clap_complete::CompletionCandidate> { |
src/cargo/util/command_prelude.rs
Outdated
| get_packages_from_metadata() | ||
| .unwrap_or_default() | ||
| .into_iter() | ||
| .map(|pkg| clap_complete::CompletionCandidate::new(pkg.name().as_str())) |
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.
Let's include the package descriptions
src/cargo/util/command_prelude.rs
Outdated
| .collect::<Vec<_>>() | ||
| } | ||
|
|
||
| fn get_packages_from_metadata() -> CargoResult<Vec<Package>> { |
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.
| fn get_packages_from_metadata() -> CargoResult<Vec<Package>> { | |
| fn get_ws_member_packages() -> CargoResult<Vec<Package>> { |
|
☔ The latest upstream changes (presumably #14535) made this pull request unmergeable. Please resolve the merge conflicts. |
1aaae04 to
869064b
Compare
src/cargo/util/command_prelude.rs
Outdated
| .help_heading(heading::PACKAGE_SELECTION) | ||
| .add(clap_complete::ArgValueCandidates::new( | ||
| get_ws_member_candidates, | ||
| )), |
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.
Looks like cargo uninstall uses this flag for the same reason as the positional argment
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.
arg_package_spec_no_all( calls this
cargo treeuses to refer to any package in the dependency graph
arg_package_spec calls that but all uses look good
…nds during compile time.
…` / `cargo tree --package <TAB>`
869064b to
2bac0b6
Compare
| .help_heading(heading::PACKAGE_SELECTION), | ||
| .help_heading(heading::PACKAGE_SELECTION) | ||
| .add(clap_complete::ArgValueCandidates::new(move || { | ||
| if ["build", "tree"].contains(&name.as_str()) { |
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 is subtle and going to be very confusing. I wonder if we should better organize the arguments by what kind of package is being requested
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.
While implementing the completion, I discovered that parameters with the same name require different values under different subcommands. To minimize disruption to the original code, I added the _name interface, which allows the subcommand being used to be determined at compile time. Is there a better way to determine what kind of package is being requested?
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.
Some ideas I thought of
- We could have different
arg_packagefunctions for different roles - We could accept a completer as an argument
|
☔ The latest upstream changes (possibly 307cbfd) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
### What does this PR try to resolve? Add dynamic completions for the various `-p <package>` arguments. Fixes #15004 ``` cargo bench|build|check|doc|fix|test -p <tab>` cargo package|publish -p <tab> cargo add|pkgid|remove|report|run|rustc|rustdoc -p <tab> cargo uninstall -p <tab> cargo tree -p <tab> -i <tab> cargo clean -p <tab> # not implemented ``` Supersedes #14553 and #15338 --- EDIT: the second implementation has been chosen In the first commit I implemented the different completions for different usages by splitting the `arg_package` methods into multiple ones if necessary: ``` * arg_package_spec * arg_package_spec_no_all * arg_installed_package_spec_no_all <- new (for cargo uninstall) * arg_dependency_package_spec_no_all <- new (for cargo tree) * arg_clean_package_spec_simple <- new (for cargo clean) * arg_package_spec_simple * arg_package ``` In the second commit I tried to instead pass an `ArgValueCandidates` into the function to prevent that duplication. ``` * arg_package_spec * arg_package_spec_no_all (ArgValueCandidates) * arg_package_spec_simple (ArgValueCandidates) * arg_package ``` I think I have a small preference towards the latter, but no strong opinion.
What does this PR try to resolve?
Tracking issue github.com/rust-lang/cargo/issues/14520
Add custom completer for
cargo build --package <TAB>Fixes #15004