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.
feat: Add custom completer for completing registry name
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for completing `cargo publish --registry <TAB>` and `cargo add --registry <TAB>`.
Document build-plan as being deprecated
This adds a note to the build-plan documentation that it is deprecated. I do not think it will make any progress as it is. In the future, we should remove the feature (#7902), possibly with a code-warning ahead of time.
fix(complete): Don't complete files for any value
### What does this PR try to resolve?
We now need to opt-in to path completions for values, which can be as simple as setting the value parser to be for `PathBuf`s.
We'll now show a lot less irrelevant completions.
### How should we test and review this PR?
### Additional information
fix: avoid inserting duplicate `dylib_path_envvar` when calling `cargo run` recursively
### What does this PR try to resolve?
If the current program started by `cargo run` recursively call into `cargo run`, the second `cargo run` will insert `search_path` into `dylib_path_envvar` again.
Fixes#14194
### How should we test and review this PR?
The first commit adds the test to reflect the issue. The first call to `cargo run` stores the dylib search path env var to a file. Subsequent calls verify that env var remains the same.
The second commit fixes the behavior by checking if env vars in `search_path` are a prefix of the slice of env vars in `dylib_path_envvar`.
We now need to opt-in to path completions for values, which can be as
simple as setting the value parser to be for `PathBuf`s.
We'll now show a lot less irrelevant completions.
docs(ref): Expand on MSRV
### What does this PR try to resolve?
The need for this has been growing and becomes especially important with the upcoming MSRV aware resolver
We will be making having an MSRV easier so we need to meet those maintainers where they are and help them.
In particular, this covers
- What setting an MSRV does
- What "support" in MSRV means, according to the definition we developed during the review of [RFC 3537](https://rust-lang.github.io/rfcs/3537-msrv-resolver.html)
- Background and guidance on setting an MSRV policy
### How should we test and review this PR?
### Additional information
This intentionally leaves out anything related to the MSRV-aware resolver as that will be handled as the feature is stabilized.
docs(ref): Highleft whats left for msrv-policy
### What does this PR try to resolve?
While there is a tracking issue for these,
I didn't want to have everything under `msrv-policy` to be stabilized,
making it look like it should be moved to the Stable section of the
page, when there are independently stabilizable pieces missing.
### How should we test and review this PR?
### Additional information
This is prep for stabilizing MSRV-aware resover
While there is a tracking issue for these,
I didn't want to have everything under `msrv-policy` to be stabilized,
making it look like it should be moved to the Stable section of the
page, when there are independently stabilizable pieces missing.
It doesn't "guide" people through a topic but explains in a more
top-down fashion what caches exist and is not particularly a common
topic people need to know.
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.
chore(deps): update tar to 0.4.42
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 everywhere the `tar::Builder` is used.
Closes#14594. CC: `@weihanglo,` `@alexcrichton.`
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.
fix: Remove implicit feature removal
### What does this PR try to resolve?
Due to problems we ran into with #14016, we're removing implicit features from the 2024 edition to give ourselves more time to design it as we should.
### How should we test and review this PR?
### Additional information
I could have added a new flag for this or made an EditionNext but I decided to remove it in the hopes to avoid any path dependency in solving this the next time.
Due to problems we ran into with #14016, we're removing implicit
features from the 2024 edition to give ourselves more time to design it
as we should.
I could have added a new flag for this or made an EditionNext but I
decided to remove it in the hopes to avoid any path dependency in
solving this the next time.
docs(ref): Clean up language for `package.rust-version`
### What does this PR try to resolve?
Some small tweaks I noticed as I was working on putting in more MSRV policy guidance.
### How should we test and review this PR?
### Additional information
Ideally, we have rust-version checks on more fields and we shouldn't have to specify
every variant of this.
By removing this, it gives us more breathing room to expand the text
more generally.
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.
`artifact` field is an (absolute) path to emitted artifact like
/home/projects/foo/target/debug/deps/libbar-73d672db2af2c9a8.rmeta
It is worth not copying them.
Found this during PR review.
We could leverage `#[serde(borrow)]` for zero-copy deserialization for
messages from the compiler.
We can't use `&str` fields because they may contain escape sequences
in the future, which fails the deserialization.
See https://github.com/serde-rs/json/issues/742
feat: lockfile path implies --locked on cargo install
Follow-up of https://github.com/rust-lang/cargo/issues/14421
Resolving one of the items
> cargo install should make --lockfile-path imply --locked
Simply mirrored behavior as if `--locked` was provided (on creating the workspace)
feat(toml): Add `autolib`
### What does this PR try to resolve?
PR #5335 added `autobins`, etc for #5330. Nowhere in there is
discussion of `autolib`.
Cargo script disables support for additional build-targets by disabling
discovery.
Except we don't have a way to disable discovery of `autolib`, leading to #14476.
By adding `autolib`, we can continue in that direction.
This also allows us to bypass inferring of libs on published packages,
like all other build-targets which were handled in #13849.
Fixes#14476
### How should we test and review this PR?
### Additional information
As this seems fairly low controversy, this insta-stabilizes the field.
In prior versions of Cargo, users will get an "unused manifest key"
warning.
For packages where this is set by `cargo publish`, the warning will be suppressed and things will work as normal.
For `cargo vendor`, the same except there will be some churn in the
vendored source as this field will now be set.
For local development, it should be rare to set `autolib` so the lack of
error by discovering a file when this is set shouldn't be a problem.
fix: correct error count for `cargo check --message-format json`
Hi! This is my first time contributing to Cargo. If there is anything that I need to do, please let me know!
(I'm not sure whether the commit message is aligned with the Cargo's convention. If it doesn't, I'm willing to modify it!)
This PR resolves the issue with incorrect error count and ensures warnings are correctly displayed when using `cargo check --message-format json`.
Fixes#14472
