feat: Add custom completer for completing cargo build --packge <TAB>#14553
feat: Add custom completer for completing cargo build --packge <TAB>#14553shannmu wants to merge 2 commits intorust-lang:masterfrom
cargo build --packge <TAB>#14553Conversation
|
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.
| 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.
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.
| 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.
Looks like cargo uninstall uses this flag for the same reason as the positional argment
There was a problem hiding this comment.
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.
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.
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.
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