Revert "remove reference to incomplete crates.io feature from docs"
This reverts commit 1735917adc11aaa14011a187baf47a320f1c5bc5.
As discussed in #13660, my stance on removing the docs was if there wasn't a path forward.
There is work progressing on the docs.rs side which will unblock the crates.io side.
If the concern for removing the docs is for new crates, then no harm in removing it for now but also little benefit.
If its to get existing crates to change, I don't think that ecosystem churn is worth it to try to get everyone to add the link and then remove it again.
feat: Add custom completer for `cargo help <TAB>`
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo help <TAB>`
### Additional information
The current completer function is quite slow because it executes too many functions. One idea I have is to use the file!() macro to list the filenames under the commands directory, excluding mod.rs, and return them as the completion results. Would this approach be too hacky?
docs(unstable): Expand on completion documentation
### What does this PR try to resolve?
Wanting to improve the workflow for people testing completions
### How should we test and review this PR?
### Additional information
feat: Add custom completer for `cargo build --example=<TAB>`
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo build --example=<TAB>`
clap-rs/clap#5733 removed the rustup proxy so that
`CARGO_COMPLETE=bash cargo +nightly` works
(with a side benefit of removing the proxy overhead).
As a downside, cargo no longer knows it is running within rustup, so we
aren't reading `--target` candidates from rustup.
This changes the code to always try rustup. It is likely a good enough
source, even if the user isn't currently using it.
The candidates should be about the same, just rustup hides some by
default.
Hiding just means it isn't shown by default but if only hidden
candidates match, then we show them.
This reverts commit 1735917adc11aaa14011a187baf47a320f1c5bc5.
As discussed in #13660, my stance on removing the docs was if there
wasn't a path forward.
There is work progressing on the docs.rs side which will unblock the
crates.io side.
If the concern for removing the docs is for new crates, then no harm in
removing it for now but also little benefit.
If its to get existing crates to change, I don't think that ecosystem
churn is worth it to try to get everyone to add the link and then remove
it again.
remove reference to incomplete crates.io feature from docs
The cargo docs for the `documentation` field currently are written in a way that makes it sound like if I want to use docs.rs, I can just leave the field empty. However, that is not the case: leaving the field empty will never show a "Documentation" link in the search results, so there's always an unnecessary extra click to go from "type crate name into search" to reaching the docs.
This crates.io limitation is tracked at https://github.com/rust-lang/crates.io/issues/1484. It doesn't really matter whether this is a bug or a missing feature, the point is that cargo docs are misrepresenting what crates.io does in a way that leads to a suboptimal user experience (many crates without "Documentation" link in crates.io search results). Since the suggestion to document what crates.io actually does was rejected (https://github.com/rust-lang/cargo/pull/13660), I suggest we instead stop mentioning this feature at all -- that's still clearly better than mentioning it while it is not yet fully implemented / while it has some significant *undocumented* limitation.
fix(complete): Fix problems on my machine
### What does this PR try to resolve?
This pulls in
- clap-rs/clap#5731 for `IFS` oddities I had
- clap-rs/clap#5733 with the hope that this makes `CARGO_COMPLETE_BASH cargo +nightly` just work
### How should we test and review this PR?
### Additional information
`clap` was completed next to `clap_complete` because `clap_complete` depends on unstable features from `clap`.
None should have changed in this time window but I wanted to exercise caution.
This pulls in
- clap-rs/clap#5731 for `IFS` oddities I had
- clap-rs/clap#5733 with the hope that this makes `CARGO_COMPLETE_BASH cargo +nightly` just work
`clap` was completed next to `clap_complete` because `clap_complete`
depends on unstable features from `clap`.
None should have changed in this time window but I wanted to exercise
caution.
feat: Add custom completer for completing benchmark names
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo build --bench=<TAB>`
feat: Add custom completer for completing test names
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo test --test <TAB>`
feat: Add custom completer for completing target triple
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo build --target=<TAB>`
feat: Add custom completer for `cargo -Z <TAB>`
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo -Z <TAB>`
feat: Add custom completer for completing installed binaries
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo uninstall <TAB>`
feat: Add custom completer for completing bin names
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo build --bin=<TAB>`
Disable the shell_completions tests
The shell_completions tests have a few issues that are causing some problems. See https://github.com/rust-lang/cargo/issues/14545 for a description. This disables the tests until those can get resolved.
fix(vendor): trust crate version only when coming from registries
### What does this PR try to resolve?
Fixes#8181
Relates to #11897 and #14525
### How should we test and review this PR?
As mentioned in the contribution guide, I made a first commit adding a test that passes with the actual behaviour. Then, I made a second commit with a fix and modified the test with the new expected behaviour.
### Additional information
The fix doesn't take into account switching from a git dependency to crates.io, which is not handled correctly on master either, and would probably require the vendoring to serialize the source ID to detect source changes.
I specifically limited the trust of immutable version to crates.io, but it could be extended to other registries.
docs: Feature resolver version 2: clarify use of 'target'
IIUC, these two uses of the word `target` right next to each other in the docs actually have different meaning. That is kind of confusing, so add disambiguators and links to the glossary that should help clarify this.
feat: Add native comlpetion with CompleteEnv under the nightly
### What does this PR try to resolve?
Related issue https://github.com/rust-lang/cargo/issues/6645
Tracking issue https://github.com/rust-lang/cargo/issues/14520
This PR is the first step to move cargo shell completions to native completions by using `clap_complete` crate. It makes users could complete cargo subcommand and flags.
By using `clap_complete` crate, we could extend the supported shells to Bash, Zsh, Elvish, Fish, and PowerShell. However, at the current stage, the support for PowerShell in `clap_complete` is not fully developed.
See https://github.com/clap-rs/clap/issues/3166 to get more context about what features `clap_complete` has supported.
### How to test and review this PR?
1. Build a test environment, including the necessary short completion scripts, and the `complete` function to start an interactive shell with the help of a pty device and obtain completion results.
2. Simply test the completion results of subcommands in bash, zsh, fish, elvish.
