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`
Before, we'd render the source for TOML syntax errors but not semantic errors.
Now we render for both.
Originally I changed `parse_document` to returned `T: DeserializeOwned`
but that adds an extra "could not parse TOML" which is both redundant
and makes it sound like its a syntax issue.
refactor(install): Move value parsing to clap
### What does this PR try to resolve?
Originally, I thought this was going to help some of my other work but it won't. Instead I decided to finish and post this PR in case there was interest since `@weihanglo` expressed interest in using `Arg::value_parser` more and this demonstrates that.
### How should we test and review this PR?
A commit at a time. There seemed to be existing tests for some of the error changes.
fix: Set MSRV for internal packages
### What does this PR try to resolve?
Correctly communicates the MSRV we support to our users.
For packages that are more generally mean to be used by other people, I've punted on for now (see ehuss' comment on this PR). We'll likely need to figure this out for #12432 though
### Additional information
This is prep for a future change which will have us use a fixed rust version for the semver tests with a PR updating them.
fix(log): Use a more compact relative-time format
This changes logged messages from
```
2023-08-23T01:01:59.922018Z DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
To
```
0.041729583s DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
Benefits
- Less horizontal space taken up in boilerplate
- Easier to compare within a run
Downsides
- Harder to correlate with other processes, like with crates.io server operations
This gives us up to 4 digits for seconds which should be sufficient for cargo build times.
We could make this more compact by dropping the digits of precision from 9 to 6 but that would require a custom Timer which might be a paint to keep in sync between packages.
This changes logged messages from
```
2023-08-23T01:01:59.922018Z DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
To
```
0.041729583s DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
Benefits
- Less horizontal space taken up in boilerplate
- Easier to compare within a run
Downsides
- Harder to correlate with other processes, like with crates.io server
operations
This gives us up to 4 digits for seconds which should be sufficient for
cargo build times.
We could make this more compact by dropping the digits of precision from
9 to 6 but that would require a custom Timer which might be a paint to
keep in sync between packages.
config: merge lists in precedence order
When merging configuration lists, the current order does not match the expected precedence. This makes merged lists follow precedence order, with higher precedence items merged later in lists.
When a list in configuration exists in multiple places, Cargo merges the lists together. The ordering of this merging is unexpected and does not follow the precedence rules that non-list configuration uses.
The current merging order appears to be:
* project-specific `config.toml`
* global `config.toml`
* command-line (`--config`)
* environment variable (`CARGO_*`)
This PR changes the order to follow the precedence rules with higher precedence configuration merging later in the lists.
* global `config.toml`
* project-specific `config.toml`
* environment variable (`CARGO_*`)
* command-line (`--config`)
This aligns with config such as `build.rustflags` where later flags take precedence over earlier ones.
Since `--config` is relatively new, it's unlikely to cause too much breakage by making it come after environment variables.
Switching global and project-specific ordering is more likely to cause breakage, since it's been around longer (reported as an issue in #8128). Projects relying on global configuration flags (in `$CARGO_HOME\config.toml` or in `.cargo/config.toml` further from the project) being merged first in lists will be broken.
For most uses of merged lists (such as `build.rustflags`), if the flags do not conflict with each other, there will be no impact.
Fixes#12506Fixes#8128
