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 (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)
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.
fix(package): Normalize paths in `Cargo.toml`
### What does this PR try to resolve?
On the surface, this resolves problems that aren't too big of a deal
- Clean up redundant information in paths (e.g. `.////.//foo.rs` being `foo.rs`) which is just visual
- Switch paths with `\` in them to `/`
However, this is prep for #13713 where these will be a much bigger deal
- If the user does `./foo.rs`, we might fail to compare that with the list of files included in the package
- We'll generate paths with `\` and need to make sure the packages can still be used on Windows
### How should we test and review this PR?
### Additional information
refactor: Track when MSRV is explicitly set, either way
### What does this PR try to resolve?
This will hopefully help when merging between CLI and config with #13540.
### How should we test and review this PR?
### Additional information
For now, this is more for visual consistency.
However, this blocks #13713 as we need to be able to make these paths
comparable to what is included in the package.
