Add a `--dry-run` flag to the `install` command
### What does this PR try to resolve?
This PR add the `--dry-run` flag to the `cargo install` command (see #11123).
I've tried to do the bare minimal for this flag to work without changing anything in the output.
In my opinion, the `--dry-run` flag should mimic as close as possible the behavior of the normal command to avoid missing potential issue in the normal execution. ~~Currently we're missing information about where the binary will be installed.~~
Unlike #13598 this PR:
- Include as much of the compilation process as possible without actually compiling
- use the information provided by `BuildContext` instead of `InstallablePackage::new`
- in the same way as `unit_graph`, it add a `dry_run` to the `CompileOptions` and return a `Compilation::new` from the function `compile_ws` without actually compiling.
- keeps the output the same rather than adding status messages indicating which very broad actions would be performed
- ~~remove some warning not relevant in the case of a `--dry-run`~~
Like #13598, the version check and crate downloads still occur.
### How should we test and review this PR?
The first commit include a unit tests to ensure that no binary is actually installed after the dry run.
There is also a snapshot test that show the diff output of the `--help` flag.
### Additional information
Tests and documentation done in #13598, may be cherry picked into this PR if needed.
fix(resolve): Don't list transitive, incompatible dependencies as available
### What does this PR try to resolve?
We have limited capability to clearly communicate to the user the different update states without overwhelming them.
Before we showed all versions that were behind, with color distinguishing how actionable they are.
Color doesn't communicate enough though and we don't want to add footnotes to clarify everything.
For now, the least useful messages will be removed, available, transitive, incompatible versions. These only give the user a hint of tech debt within their dependencies and can't be acted upon.
This is part of #13908
### How should we test and review this PR?
### Additional information
feat(complete): Upgrade clap_complete
Changes:
- Change completion order to subcommands, positional values, flags
- When completing `-[TAB]`, prioritize shorts over longs
- De-duplicate completions that have the same result (longs, shorts, aliases)
- Group candidates from the same `CompletionCandidate::tag`
- Sort candidates within a `CompletionCandidate::tag` by their `display_order`
Changes:
- Change completion order to subcommands, positional values, flags
- When completing `-[TAB]`, prioritize shorts over longs
- De-duplicate completions that have the same result (longs, shorts, aliases)
- Group candidates from the same `CompletionCandidate::tag`
- Sort candidates within a `CompletionCandidate::tag` by their `display_order`
fix(complete): Harden `--target` completions
### What does this PR try to resolve?
I found `--target` wasn't working with rustup as I expected, so this fixes it. We generally only reference rustup if we are running under it but I think in UX code like this, with a fallback scheme, this should be reasonable enough.
### How should we test and review this PR?
### Additional information
Cleanup duplicated check-cfg lint logic
### What does this PR try to resolve?
This PR clean-ups some duplication left by https://github.com/rust-lang/cargo/pull/13958, because of Cargo MSRV.
Fixes https://github.com/rust-lang/cargo/issues/13975
### How should we test and review this PR?
The tests in `tests/testsuite/check_cfg.rs` show no change in behaviours (except for the better error messages). I suggest maybe reviewing commit by commit.
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.
