feat(resolve): Tell the user the style of resovle done
### What does this PR try to resolve?
This is to help with https://github.com/rust-lang/cargo/issues/9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest compatible version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest compatible versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
### How should we test and review this PR?
### Additional information
docs: update `checkout` GitHub action version
### What does this PR try to resolve?
This PR updates the GitHub CI examples in The Cargo Book to use the latest version of the `actions/checkout` GitHub action, since using `actions/checkout@v3` (currently used in the examples) produces warnings about deprecated Node.js 16 (see also [GitHub Actions: Transitioning from Node 16 to Node 20](https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/) blog post).
Also, v4 is already used in the "Verifying `rust-version`" example:
a9f86addbc/src/doc/src/guide/continuous-integration.md?plain=1#L174
Recategorize cargo test's `--doc` flag under "Target Selection"
### What does this PR try to resolve?
In `cargo help test`, the `--doc` flag is listed under a section called "Target Selection" next to `--lib`, `--bin`, `--bins`, `--example`, `--examples`, `--test`, `--tests`, `--bench`, `--benches`, and `--all-targets`.
But in `cargo test --help`, it was instead listed in an "Options" section next to `--no-run`, `--message-format`, `--color`, etc, which seems less appropriate than "Target Selection".
### How should we test and review this PR?
- `cargo build --release`
- `cargo test --release --test testsuite -- cargo_test::help::case`
- `target/release/cargo test --help`
- `target/release/cargo help test` (unchanged)
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
Reword sentence describing workspace toml for clarity
Judging by the commit history, the original sentence was written before the `[patch]` and `[profile]` sections were added and since those sections do not go underneath the workspace table the original sentence needed to be updated.
Judging by the commit history, the original sentence was written before the `[patch]` and `[profile]` sections were added and since those sections do not go underneath the workspace table the original sentence needed to be updated.
refactor(config): Consistently use kebab-case
This shouldn't change the behavior but makes it safer if
- We add new fields where it will matter
- Copy/paste these for new structs
I did not change things related to the Index because we are already stuck with that case (whether we want it or not)
Came across this when working on #13540 and almost made the mistake of copying what was already there
feat(resolve): Fallback to 'rustc -V' for MSRV resolving
### What does this PR try to resolve?
This is part of #9930 and adds a fallback if the rust-version isn't set
### How should we test and review this PR?
Tests are added in a separate commit so people can see how the behavior changed.
### Additional information
This shouldn't change the behavior but makes it safer if
- We add new fields where it will matter
- Copy/paste these for new structs
I did not change things related to the Index because we are already
stuck with that case (whether we want it or not)
feat(cli): Add --ignore-rust-version to update/generate-lockfile
### What does this PR try to resolve?
This is part of #9930 and extends `--ignore-rust-version` to `cargo update` and `cargo generate-lockfile`
### How should we test and review this PR?
First commit sets up tests
### Additional information
`cargo package -p no-exist` emitt error when the -p `package` not found
### What does this PR try to resolve?
Fixes#13719
If `-p` is used, and the spec doesn't match any member, we emit an error like `cargo publish -p` does.
### How should we test and review this PR?
The first commit add a test to show the issue, the next commit add the check logic to fix it.
### Additional information
fix(help): Generalize --ignore-rust-version
### What does this PR try to resolve?
This is part of #9930 and updates for the help to accommodate #13738 and adding `--ignore-rust-version` to `cargo update` for when they are stable
This includes
- Moving `--ignore-rust-version` to be under the "Manifest options" header
- Generalizing the help description
### How should we test and review this PR?
### Additional information
test: don't compress test registry crates
They are still nominally gzipped, but using `Compression::none()` makes
them consistent even across zlib and zlib-ng, and this fixes checksum
differences in the testsuite. There is a one-time update of all those
checksums to catch up with this change though.
r? `@weihanglo`
feat(reslve): Respect '--ignore-rust-version'
### What does this PR try to resolve?
This is a part of #9930.
### How should we test and review this PR?
I had considered several ways of implementing this. I first looked at passing this into `ops::resolve*`.
.This would get a bit annoying with the function signature, so I considered moving it to a builder..
Each of the entry points is slightly different with different ownership needs, making it hard to have a common abstraction.
In doing this, I noticed we currently pass some state around to the resolver via `Workspace`, so I mirrored that.
The nice thing about this location is it provides a good place to hook in config and `package.resolve` so they affect this.
### Additional information
They are still nominally gzipped, but using `Compression::none()` makes
them consistent even across zlib and zlib-ng, and this fixes checksum
differences in the testsuite. There is a one-time update of all those
checksums to catch up with this change though.
refactor: Remove `rust_2024_compatibility` lint group
The `rust_2024_compatibility` lint group was added as a way to be compatible with `Rust`. This group is meant to be used when switching to the 2024 edition (usually enabled by `cargo fix --edition`). Since we are not going to be interacting with `cargo fix` in the standard way to fix edition lints, this group is not needed at this time. Removing this will (slightly) reduce the complexity of working on things for the 2024 edition.
This assumes that if any of the machine applicable fixes in
a diagnostic suggestion is a duplicate, we should see the
entire suggestion as a duplicate.
Ed Page
bors
Naglis Jonaitis
David Tolnay
jw013
Ralf Jung
Lin Yihai
Josh Stone
Scott Schafer
Weihang Lo