Skip to content

feat: Add custom completer for completing cargo build --packge <TAB>#15338

Closed
nooma-42 wants to merge 3 commits intorust-lang:masterfrom
nooma-42:cargo-package-completer
Closed

feat: Add custom completer for completing cargo build --packge <TAB>#15338
nooma-42 wants to merge 3 commits intorust-lang:masterfrom
nooma-42:cargo-package-completer

Conversation

@nooma-42
Copy link
Contributor

@nooma-42 nooma-42 commented Mar 21, 2025

What does this PR try to resolve?

Fixes #15004

How should we test and review this PR?

Additional information

This supersedes #14553

@rustbot
Copy link
Collaborator

rustbot commented Mar 21, 2025

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added A-cli Area: Command-line interface, option parsing, etc. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 21, 2025
@rustbot
Copy link
Collaborator

rustbot commented Mar 21, 2025

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

@epage
Copy link
Contributor

epage commented Mar 24, 2025

In #14553 (comment), I expressed concern over keying off of the name of the command for deciding what kind of completions should be done.

github-merge-queue bot pushed a commit that referenced this pull request Nov 6, 2025
### 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.
@epage
Copy link
Contributor

epage commented Jan 29, 2026

This ended up being resolved by #16210.

@epage epage closed this Jan 29, 2026
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-cli Area: Command-line interface, option parsing, etc.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cli suggestions for --package

5 participants

Comments