fix(update): Make `-p` more convenient by being positional
Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options.
For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`).
This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`.
As for `--help` formatting, I'm mixed on whether `[SPEC]...` should be at the top like other positionals or should be relegated to "Package selection". I went with the latter mostly to make it easier to visualize the less common choice.
Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in #12425.
Set tracing target for networking messages.
This changes the log messages for messages related to network traffic to use the "network" tracing target. This makes it easier to do `CARGO_LOG=network=trace CARGO_HTTP_DEBUG=true` instead of trying to figure out which modules to include (and to avoid `CARGO_LOG=trace` which can be too noisy). For example, #12290 moved the location of some log messages to a different module, which broke the documented workflow of using `CARGO_LOG=cargo::ops::registry=debug` to get networking information.
feat(resolver): **Very** preliminary MSRV resolver support
### What does this PR try to resolve?
A bare bones implementation of an MSRV resolver that is good enough for people running on nightly when they really need it but is not ready for general use.
Current limitations
- Does not honor `--ignore-version`
- Gives terrible error messages
- Nothing is done yet regarding `cargo install`
- Doesn't inform the user when choosing non-latest
These will be noted in #9930 on merge.
Implementation wise, this is yet another hack (sorry `@Eh2406).` Our expectation to get this GA is to refactor the resolver to make the cargo/resolver boundary look a little more like the cargo/pubgrub boundary so we can better control policy without any of these hacks which will also make having all of the policy we need for this easier to maintain.
This is a part of #9930
### How should we test and review this PR?
Per commit
Update git2
This is a routine update of libgit2.
Changelog: https://github.com/rust-lang/git2-rs/blob/master/CHANGELOG.md#0180---2023-08-28
There is a pretty large number of changes, but I don't think any of them are particularly of interest in terms of changes users will see. Most of the changes are opt-in and we don't opt-in to them (SHA256, Windows schannel, or shallow clone).
Improve deserialization errors of untagged enums
### What does this PR try to resolve?
```toml
# .cargo/config.toml
[http]
ssl-version.min = false
```
**Before:**
```console
$ cargo check
error: data did not match any variant of untagged enum SslVersionConfig
```
**After:**
```console
$ cargo check
error: error in /path/to/.cargo/config.toml: could not load config key `http.ssl-version`
Caused by:
error in /path/to/.cargo/config.toml: `http.ssl-version.min` expected a string, but found a boolean
```
### How should we test and review this PR?
The first commit adds tests showing the pre-existing error messages — mostly just _"data did not match any variant of untagged enum T"_ with no location information. The second commit replaces all `#[derive(Deserialize)] #[serde(untagged)]` with Deserialize impls based on https://docs.rs/serde-untagged/0.1, showing the effect on the error messages.
Tested with `cargo test`, and by handwriting some bad .cargo/config.toml files and looking at the error produced by `rust-lang/cargo/target/release/cargo check`.
Define {{command}} for use in src/doc/man/includes
I am interested in using this in https://github.com/rust-lang/cargo/pull/12568.
```diff
{{#option "`--keep-going`"}}
Build as many crates in the dependency graph as possible, rather than aborting
the build on the first one that fails to build.
For example if the current package depends on dependencies `fails` and `works`,
- one of which fails to build, `cargo check -j1` may or may not build the one that
+ one of which fails to build, `cargo {{command}} -j1` may or may not build the one that
succeeds (depending on which one of the two builds Cargo picked to run first),
- whereas `cargo check -j1 --keep-going` would definitely run both builds, even if
+ whereas `cargo {{command}} -j1 --keep-going` would definitely run both builds, even if
the one run first fails.
{{/option}}
```
Update serde
This updates serde to the latest version (essentially reverting #12528). The current lock is preventing publishing of credential crates because they were published with a newer version.
string leek is stable
### What does this PR try to resolve?
String leek is now stable so lets use it.
### How should we test and review this PR?
Code compiles and test run.
refactor: Pull out cargo-add MSRV code for reuse
### What does this PR try to resolve?
#12078 added MSRV code in `cargo add`. Our assumption when writing it is that we'd need to generalize the code before reusing it in other places, like `cargo install`. This PR focused purely on that refactor because I'm hopeful it will be useful for other work I'm doing. Despite not having a user for this yet, I think the `cargo install` case is inevitable and I feel this does a bit to clean up MSRV related code by using a more specific type everywhere.
### How should we test and review this PR?
Each commit gradually progresses things along
Support dependencies from registries for artifact dependencies, take 2
This is a continuation of #12062, and closes#10405.
r? `@ehuss`
Here are things this PR changes:
1. Add information about artifact dependencies to the index. This bumps index_v to 3 for people using bindeps.
2. Make `RustcTargetData` mutable for the feature resolver. This is so that we can query rustc for target info as late as resolving features, as that is when we really know if a package is really going to be used.
fix(toml): Improve parse errors
### What does this PR try to resolve?
When we adopted `toml_edit`, we got TOML syntax errors that showed the context for where the error occurred. However, the work was not done to extend this to semantic errors reported by serde.
This updates `Cargo.toml` and `Cargo.lock` code to provide that context on semantic errors. `config.toml` is not done because the schema is decentralized.
In theory, this will also improve performance because we aren't having to allocate a lot of intermediate data to then throw away for every `Cargo.toml` we read.
### How should we test and review this PR?
Check by commit to see this change gradually.
- The `package.cargo-features` change was made to drop out dependence on `toml::Table` so we could do the direct deserialization
Create dedicated unstable flag for asymmetric-token
Asymmetric tokens are gated by `-Zcredential-process`. Since we're considering stabilizing that soon, this moves asymmetric token support to have its own unstable flag.
It was previously gated by `-Zregistry-auth`, and some of the docs were not updated when it moved.
r? `@Eh2406`
