Tracking Issue for native-completion

[shannmu]

Summary

Original issue: #6645
Implementation:

• feat: Add native comlpetion with CompleteEnv under the nightly #14493
• Add custom completer for cargo uninstall <TAB> (feat: Add custom completer for completing installed binaries #14534)
• Add custom completer for cargo build --bin=<TAB> (feat: Add custom completer for completing bin names #14533)
• Add custom completer for cargo build --bench=<TAB> (feat: Add custom completer for completing benchmark names #14532)
• Add custom completer for cargo build --example=<TAB> (feat: Add custom completer for cargo build --example=<TAB> #14531)
• Add custom completer for cargo test --test=<TAB> (feat: Add custom completer for completing test names #14548)
• Add custom completer for cargo update <TAB> (feat: Add support for completing cargo update <TAB> #14552)
• Add custom completer for cargo build --package=<TAB> (cli suggestions for --package #15004, feat: Add custom completer for completing cargo build --packge <TAB> #14553)
• Add custom completer for cargo help <TAB> (feat: Add custom completer for cargo help <TAB> #14557)
• Add custom completer for cargo -Z <TAB> (feat: Add custom completer for cargo -Z <TAB> #14536)
• Add custom completer for cargo build --target=<TAB> (feat: Add custom completer for completing target triple #14535)
• Add custom completer for cargo +<TAB> to complete toolchain name
• Add custom completer for cargo <TAB> to complete aliases defined in config.toml
• Add custom completer for cargo <TAB> to complete third-party subcommand names
• Ensure vcs, color, and message format possible values are completed
• Add custom completer for cargo publish --registry=<TAB> (feat: Add custom completer for completing registry name #14656)
• Add custom completer for cargo add --registry=<TAB> (feat: Add custom completer for completing registry name #14656)
• Add custom completer for --features
• Add custom completer for cargo add <TAB> and cargo install <TAB> using crate.io search API
• Registering completions / using completions with +toolchain argument
• shell_completions test issues #14545

Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#native-completions

Testing instructions: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#native-completions

Unresolved Issues

• Some tests are disabled on macOS.
• Distinguish whether different subcommands require path fallback.
• Completion candidates generation test code per completer.

Open Questions

• What should we support?
  • Today, cargo supports bash, zsh
  • Currently, this adds fish, elvish, powershell
  • rustup supports bash, fish, zsh, powershell, elvish
  • Are all of sufficient quality? powershell being the biggest question

Future Extensions

• Add custom completer for cargo <TAB> to cargo scripts
• Add custom completer for cargo builder --manifest-path<TAB>
• Add custom completer for cargo test <TAB>
• Add custom completer for cargo --explain=<TAB>
• Add custom completer for cargo builder --features=<TAB>
• Add custom completer for cargo builder --profile=<TAB>
• Add custom completer for cargo install --path<TAB>
• Add custom completer for cargo add --path<TAB>

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[epage]

@shannmu in testing this, some of the output isn't ideal. The new completer is respecting the documented behavior in ValueHint::Unknown which means there are cases like cargo add [TAB] that show file paths when we shouldn't. On the other hand, this is a good default for cargo install --path [TAB].

We'll need to identify places to sprinkle ValueHint::Other

[epage]

Fish does a lot of parsing of Cargo output and people doing that is a reason we're careful about changing our output. It would be good to see if we could be feature parity with them and get them to switch to our completion generation.

Looking over what they do in addition to things specified

• They complete --features
• cargo add and cargo install complete using the crates.io search API
  • This is questionable because that can disclose confidential information

See https://github.com/fish-shell/fish-shell/blob/master/share/completions/cargo.fish

[shannmu]

We'll need to identify places to sprinkle ValueHint::Other

The file paths fallback does indeed affect the user experience. I was thinking if we could temporarily document this issue in the tracking issue. Once the main logic of the various completers is resolved, we can revisit and determine in which cases we don't need the file paths fallback and in which cases it is necessary.

[shannmu]

Is there any difference in the completion of the --registry option between cargo publish and cargo add?

[epage]

@shannmu cargo add corresponds to https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-other-registries while cargo publish --registry is https://doc.rust-lang.org/cargo/commands/cargo-publish.html#publish-options

Both are defined as coming from config, so they should be the same.

[epage]

Add custom completer for cargo to complete third-party subcommand names
Add custom completer for cargo to complete aliases defined in config.toml
Add custom completer for cargo + to complete toolchain name

This would be handled by completing the external subcommand. Support for this in clap was merged in clap-rs/clap#5706.

For the first two items, an existing place where cargo collects this information is https://github.com/rust-lang/cargo/blob/master/src/bin/cargo/main.rs#L183-L254