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.
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.
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.
Do not strip debuginfo by default for MSVC
This PR disables the logic which enables debuginfo stripping by default in release mode (https://github.com/rust-lang/cargo/pull/13257) for MSVC, since it causes problems there (https://github.com/rust-lang/rust/issues/122857).
I'm not sure if this is the correct way to gate the logic on a specific target triple.
The root of the issue is that `-Cstrip=debuginfo` currently behaves like `-Cstrip=symbols` on MSVC, which causes the original optimization to break backtraces on Windows. Ultimately, this should probably be fixed in `rustc`, but that might take some further design work, therefore a faster solution would be to just special case this in Cargo for now, and remove the special case later, once it gets fixed on the `rustc` side.
Related issue: https://github.com/rust-lang/rust/issues/122857
refactor: Make lint names snake_case
When working on #13621, I somehow missed that lint names should be `snake_case` according to the [`rustc-dev-guide`](https://rustc-dev-guide.rust-lang.org/diagnostics.html#lint-naming) as well as [`RFC #344`](https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints).
This PR renames:
- `implicit-features` => `implicit_featires`
- `rust-2024-compatibility` => `rust_2024_compatibility`.
<hr>
Note: We should probably have some tooling to enforce this, but I was unsure if it belonged to this PR or another one. One solution would be to use a macro to create the `const LINT_NAME: Lint = {...}`, where `LINT_NAME` would be the `ident` as well as the `name: &'static str` and then have a method on `Lint` to make it lowercase as needed. This is what `rustc` does, and it could work well here. It would ensure snake case as `const` names need to be [`SCREAMING_SNAKE_CASE`](https://rust-lang.github.io/rfcs/0430-finalizing-naming-conventions.html#general-naming-conventions), or a warning is shown.
Use `gitoxide` for `list_files_git`
Related to #10150.
### Tasks
* [x] update `gix` to v0.60
* [x] assure this is tested (currently only git-tests run with `git2` and `gitoxide`)
* [x] allow `list_files_git` to use `gitoxide` if it is enabled as feature.
* [x] use dirwalk iterator
* [x] use new release of `gix` with necessary updates
### Review Notes
As this PR has come a long way, I decided to keep a few of the steps leading up to the final state, showing the PR's evolution in the hope it helps the review.
* Would it be better to simply use `gitoxide` for this without a switch? I don't think
it will cause more trouble than `git2`, and if there is an issue I will fix it with priority.
* In one test, the walk resolves a symlink to a submodule to individual files, including the `.git/*` folder contained in the submodule which is ignored by the walk, i.e. `submodule/*` does not contain it, but `submodule-link/*` does. This is fixed in the gitoxide version, and the `git2` version.
* I noticed that symlinks are resolved for packaging *and* are allowed to point to anywhere, even outside of package root. I left it, but felt that maybe this should be reconsidered.
### Remarks
* I love the test-suite! It's incredibly exhaustive to the point where it uncovers shortcomings in `gitoxide`, which I greatly appreciate.
* I also love `git2` as it's API for many things leads to pretty idiomatic code, and sometimes I really have to work to match it. The example here is the initial `dirwalk()` method which requires a delegate as it doesn't just collect into a `Vec` like `git2` does (for good reason). Turning that into an iterator via `dirwalk_iter()` makes it far more usable, and will definitely be good for performance as the dirwalk work is offloaded into its own thread.
This is part of #9930 for rust-lang/rfcs#3537
This will make it easier to maintain an MSRV-compliant `Cargo.toml` but
leaves validation up to the user as the resolver will pick newer
versions.
This helps the MSRV-aware workflows enumerated in
rust-lang/rfcs#3537 though it could be confusing to the workflow with an
MSRV-compatible lockfile.
PR #13561 at least raises awareness of that discrepancy.
There is an unresolved question on differences in the resolver vs
`cargo add` for dealing with an unset `rust-version`.
However, we are only stabilizing the `cargo add` side which is a very
light two-way door as this is a UX-focused command and not a
programmatic command.
This hasn't gotten much end-user testing but, as its UX focused, that
seems fine.
As such, this seems like it is ready to stabilize.
test(metadata): Show behavior with TOML-specific types
### What does this PR try to resolve?
The goal is to know if/when these change so we can have a conversation about what to do.
### How should we test and review this PR?
### Additional information
Switch to using gitoxide by default for listing files
### What does this PR try to resolve?
Uses gitoxide by for listing the contents of a git repository by default. Fixes#10150
It's possible out-opt of this change with the environment variable `__CARGO_GITOXIDE_DISABLE_LIST_FILES=1`. This opt-out mechanism is temporary and will be removed before the next release.
### How should we test and review this PR?
The newly added test fails with the `git2` implementation.
Allow precise update to prerelease.
### What does this PR try to resolve?
This is a feature that attempts to support updates to pre-release versions via `cargo update --precise`.
when `precise-pre-release` used, the prerelase version will be taking consider as compatible version. That said, we can update to any compatible pre-release version. The logic of checking the compatibility of pre-release versions is currently tentative and does not take many conditions into account, this part of the logic makes more sense when implemented in semver.
Use `-Zunstable-options` instead of `-Zprecise-pre-release`.
### How should we test and review this PR?
### Additional information
Part of https://github.com/rust-lang/cargo/issues/13290
fix(toml): Warn on unused workspace.dependencies keys on virtual workspaces
### What does this PR try to resolve?
This splits out refactors that build on #13589 in preparation for resolving #13456.
As part of those refactors, I noticed an inconsistency on when we warn for unused keys. We have parallel code paths between `to_virtual_manifest` and `to_real_manifest` and only one got updated on a change. This syncs them up. Hopefully the end state this builds to will reduce duplication.
### How should we test and review this PR?
### Additional information
