I'm unsure how we should be replacing these use cases, so I'm exploring
keeping them but making them use snapbox under the hood.
Part of the intent of snapbox is that it provides you the building
blocks to make what you need.
test(gc): Update remaining unordered tests to snapbox
### What does this PR try to resolve?
This gets rid of the last unordered tests and removes the functions from `cargo-test-support` as part of #14039
Some tests are being less specific than they were before but in talking to ehuss, it sounded like that was ok.
### How should we test and review this PR?
### Additional information
Add transactional semantics to `rustfix`
### What does this PR try to resolve?
This PR adds transactional semantics to `rustfix::Data`, enabling `rustfix::CodeFix` to apply `Suggestion`s as atomic units and rollback partially-applied changes when they conflict with existing ones. The basic approach and goals are discussed [in a comment on issue 14699](https://github.com/rust-lang/cargo/issues/14699#issuecomment-2427501232). In that comment, I proposed a solution which extended the existing `State` enumeration, but described an alternative that simplifies the overall tracking of incoming changes; this PR implements the latter.
### How should we test and review this PR?
I've added an additional test and updated the existing ones. The tests in `parse_and_replace` already cover this case, particularly thanks to https://github.com/rust-lang/cargo/pull/14765 added by `@weihanglo.` It's still a good idea to experiment with `cargo clippy --fix` on repos that match the cases described in these open issues.
### Additional information
Fixes#14699
Fixes rust-lang/rust-clippy/issues/13549
DirectorySourceOptions is marked as #[non_exhaustive], and only
exposes the Default trait, so we need to instantiate a mutable
instance using default(), and then change tpl_extension to the
value we want.
fix(util): Respect all `..`s in `normalize_path`
### What does this PR try to resolve?
The fact that `normalize_path` was only designed for absolute paths bit us when working out #14497 and so I decided to make sure it worked. The other alternative I considered was having it assert that the path was absolute.
Since I did try out the assert and Cargo tests hit it, this likely fixes something but I haven't dug through to be able to say what.
### How should we test and review this PR?
### Additional information
Encodes the version information into Cargo's fingerprint dep-info files,
so that when the format encoding changes in the future,
Cargo understands a dep-info file was outdated and doesn't bother parsing it.
Since there was no version info encoded in the old format (call it v0),
to be compatible with older cargoes,
this PR works around it with a horrible hack.
It is explained in the doc comment of `EncodedDepInfo`.
test(install): Verify 2024 edition / resolver=3 doesn't affect resolution
### What does this PR try to resolve?
I was worried there might be bugs related to this. With this out of the way, I think we'll be ready to stabilize `resolver = "3"`.
### How should we test and review this PR?
### Additional information
Added unstable-schema generation for Cargo.toml
### What does this PR try to resolve?
Added unstable-schema feature that generates JsonSchema for Cargo.toml
See #12883
finished first step of [plan](https://github.com/rust-lang/cargo/issues/12883#issuecomment-2407648385)
### Information
In cargo-util-schemas, run cargo test --feature unstable-schema . If there have been any changes to manifest.schema.json, rerun with env variable SNAPSHOTS=overwrite and it will update them.
### How should we test and review this PR?
In cargo-util-schemas run cargo test --features unstable-schema and it will generate manifest.schema.json
test: add fixes in the sat resolver
### What does this PR try to resolve?
This is a follow-up of https://github.com/rust-lang/cargo/pull/14614.
### How should we test and review this PR?
Commit 1 removes duplicate variables in the sat resolver.
Commit 2 removes useless clones in the sat resolver.
r? Eh2406
chore(deps): update rust crate pulldown-cmark to 0.12.0
### What does this PR try to resolve?
Closes#14667
### How should we test and review this PR?
Cargo build-man stopped giving errors after updating pulldown-cmark
### Additional information
initial version of checksum based freshness
Implementation for https://github.com/rust-lang/cargo/issues/14136 and resolves https://github.com/rust-lang/cargo/issues/6529
This PR implements the use of checksums in cargo fingerprints as an alternative to using mtimes. This is most useful on systems with poor mtime implementations.
This has a dependency on https://github.com/rust-lang/rust/pull/126930. It's expected this will increase the time it takes to declare a build to be fresh. Still this loss in performance may be preferable to the issues the ecosystem has had with the use of mtimes for determining freshness.
Add new intermediate boolean variables for each dependency and each dependency feature declared in a package.
This is used to simplify computation of the sat clauses.
Add support for multiple dependencies with the same name, if their kind or target is different.
A non-weak dependency feature for an optional dependency now activates a feature of the same name in the sat resolver.
This is to bring us into conformance with the [Rust crate ownership
policy](https://forge.rust-lang.org/policies/crate-ownership.html).
Items of note
- `cargo-credential-1password` is declared as Experimental as it is
intended for the community but I was unsure if we wanted to commit to
full support for it. In my mind, the ideal thing to do would be to
expatriate this to 1password.
- `home` is declared as Internal despite its wide use within the
ecosystem.
- `cargo-credential` is declared as Intentional as its an API intended
for the wider ecosystem and I didn't see a reason to declare it
experimental.
- `cargo-platform`, `cargo-util-schemas`, and `crates-io` are declared
as Intentional as they are both used internally and intended for
others to use for logic that integrates with cargo/registries.
I wondered about these being Experimental or Internal instead.
The new version of tar enables the creation of sparse tar archives by
default. The ability to read such sparse entries was added in tar
0.4.6, which has been in use starting from Cargo 0.13 and Rust 1.12.
Additionally, `docker cp` doesn't support sparse tar entries in the GNU
format. For compatibility with older versions of Rust and Cargo, as
well as with `docker cp`, this commit disables sparse archive creation
in the corresponding cases where the `tar::Builder` is used. See
#14594.
test: add support for features in the sat resolver
### What does this PR try to resolve?
This PR implements the first step of https://github.com/rust-lang/cargo/pull/11938#issuecomment-1868426431.
### How should we test and review this PR?
The first commit does some refactorings, and the second commit updates the SAT resolver.
List of boolean variables in the SAT resolver:
* One variable representing the activation of each registry package.
* One variable representing the activation of each feature of a given registry package.
* In the `sat_resolve()` method, we create an additional representing the activation of the root package.
List of clauses in the SAT resolver:
* If a package feature is activated, then the package should be activated.
* No two packages with the same links set.
* No two semver compatible versions of the same package.
* For each package:
- For each feature:
- If the package feature is activated and it depends of another feature of the same package, then it is also activated.
- If the package feature is activated and it depends of a dependency, then at least one of the compatible dependency package should be activated.
- If the package feature is activated and it depends of a feature of a dependency, then the feature of a compatible dependency package should be activated only if the compatible dependency package is activated. If this is not a weak dependency feature, then at least one of the compatible dependency package should be activated.
- For each dependency, if the package is activated and if the dependency is non-optional or has been activated, then at least one of the compatible dependency package and its required features should be activated.
* The root package has the same dependency clauses but has no features.
List of assumptions in the SAT resolver:
* The root package is activated.
* Old root packages from previous calls to `sat_resolve()` are deactivated. This is necessary since the proptest call `sat_resolve()` several times with a different root package using the same SAT resolver, and clauses relative to the root package are not removable.
