SemVer: Update documentation about removing optional dependencies
This updates the documentation cautioning against removing optional dependencies with more up-to-date information about using the `dep:` syntax in the features table. This documentation was written before `dep:`, and I just forgot to update these docs when it was stabilized.
`cargo` waits for the package to appear in the index by default these days, so these obsolete extra `sleep()` calls are just making the publish process slower now without any advantages.
util/toml: Remove duplicate `serde(rename)` attributes
The struct is already using `#[serde(rename_all = "kebab-case")]`, so the rename attributes on the individual fields seems unnecessary.
doc: differentiate defaults for split-debuginfo
### What does this PR try to resolve?
Documentation of different values for same named option in two different tools.
could fix#12243
### How should we test and review this PR?
Editor review.
feat(cli): Add '-n' to dry-run
This came from #12638 and my many small frustrations from wanting to use `-n` and not being able to.
We do not have any existing `-n` flags for this to be confused with.
I would wager that `-n` is such an entrenched short flag in build tools that it would not make sense for us to use it with any other flag.
For a survey of where `-n` is used as a short, see https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table
feat: stabilize credential-process and registry-auth
Stabilization PR for `registry-auth` and `credential-process`.
Tracking approval of this stabilization is done in the via the FCP in [#8933](https://github.com/rust-lang/cargo/issues/8933#issuecomment-1711990123). This PR is here to help reviewers of the FCP.
* Stabilizes `registry-auth` and `credential-process`
* Makes authenticated registries require a credential provider
* Adds stable documentation for credential providers and authenticated registries
Closes#8933Closes#10474
doc: clarify caret requirements
### What does this PR try to resolve?
clearing up caret version requirements
possibly fixes#12112
### How should we test and review this PR?
expert review...
feat(pkgid): Allow incomplete versions when unambigious
### What does this PR try to resolve?
This was proposed in #12425 to help sand off some of the rough edges around `cargo update` for its wider use it would be getting. Its easy to accidentally get duplicate copies packages in a repo and a pain to have to specify the full version when `cargo update -p foo@1` is sufficient to describe it.
Other effects
- profile overrides also supports this since we already allow a spec to match multiple items
- `cargo clean -p foo@...` already ignored the version, so now we also parse and ignore the partial version
- `cargo tree --prune` will now accept partial versions and will match all of them
Parts not effected:
- Replacements
- Two of the cases were found and we treat it as if the version isn't present which will error, so I think that is correct
### How should we test and review this PR?
This extracts `PartialVersion` from `RustVersion` where `RustVersion` is a more specialized variant, not allowing prerelease or build.
This works by adopting `PartialVersion` into `PackageIdSpec`. For `PackageIdSpec::query`, this will "just work".
### Additional information
fix: emit a warning for `credential-alias` shadowing
### What does this PR try to resolve?
If a `credential-alias` shadows a built-in provider the user could be confused about which provider is being used.
### How should we review this PR?
See the test to see what the warning looks like.
r? `@epage` who listed this as a concern on the FCP in #8933
Clippy
### What does this PR try to resolve?
A few more small anti-patterns from our code base. Each in their own commit, found by turning on a clippy warning and manually reviewing the changes. Most of the changes are from switching to `let-else`.
### How should we test and review this PR?
Internal refactoring and tests still pass.
### Additional information
I know we don't like "fix clippy" PR's. Sorry.
On the other hand having reviewed for these lints, I wouldn't mind turning them to warn. 🤷
