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.
fix(new): Add to workspace relative to manifest, not current-dir
### What does this PR try to resolve?
We were correctly doing this for cases like `cargo new foo` or
`cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`.
This came up when discussing #14501
### How should we test and review this PR?
### Additional information
Fix parsing of comma separated values in --crate-type flag
### What does this PR try to resolve?
According to the documentation the `--crate-type` flag accepts a comma separated list of crate types. However, these are never actually split into individual items and passed verbatim to rustc.
Since cargo fails to associate cases such as 'staticlib,cdylib' to a specific crate type internally, it has to invoke rustc to determine the output file types for this unknown crate type, which returns only the first file type of the first crate type in the list. Consequently cargo will be looking only for a single '.a' artifact on Linux to be copied to the target directory.
Fix this by splitting the list of provided crate types into individual items before further processing them.
Fixes#14498
### How should we test and review this PR?
Updated corresponding test cases
### Additional information
Include public/private dependency status in `cargo metadata`
fixes#14502
> [!TIP]
> This change can be reviewed commit-by-commit.
> Descriptions on individual commits are available to justify some decisions
`@rustbot` label Command-metadata Z-public-dependency
docs: bin source can be `src/main.rs` and/or in `src/bin/`
### What does this PR try to resolve?
This commit clarifies the doc by stating we can place a binary source as `src/main.rs` and/or in `src/bin/`.
Wording is suggested by Ed Page (`@epage).`
### How should we test and review this PR?
(It seems the only way is to check the chenge visually...)
### Additional information
Closes#14463.
This commit clarifies the doc by stating we can place a binary source as `src/main.rs` and/or in `src/bin/`.
Wording is suggested by Ed Page (@epage).
Closes#14463.
This change introduces a new method, `Dependency::serialized` which replaces the direct `Serialize` implementation on `Dependency`.
This matches the pattern used by `Package` with its `Package::serialized`, and will enable us to influence the serialization format with additional arguments.
I replaced borrowed types in `SerializedDependency` with owned variants to satisfy the borrow checker.
This matches `SerializedPackage` and shouldn't be an issue since `Dependency` is cheap to copy.
fix(toml): Don't require MSRV bump for pub/priv
### What does this PR try to resolve?
In #13308, we decided to make the feature gate for public/private dependencies non-blocking.
Generally, people opt-in to a feature that is non-blocking through `-Z` but some nightly users want an "always on" mode for this, so we offered both in #13340.
In #13340, we made both feature gates work but we did not make them non-blocking for stable, only nightly.
This change makes the feature gate non-blocking on stable.
Unfortunately, this means that 1.83 will be the MSRV for people using public dependencies. Good thing the feature is indefinitely blocked in rustc as that gives us more time.
### How should we test and review this PR?
### Additional information
In #13308, we decided to make the feature gate for public/private
dependencies non-blocking.
Generally, people opt-in to a feature that is non-blocking through `-Z`
but some nightly users want an "always on" mode for this, so we offered
both in #13340.
In #13340, we made both feature gates work but we did not make them
non-blocking for stable, only nightly.
This change makes the feature gate non-blocking on stable.
