This includes
- `cargo generate-lockfile --ignore-rust-version`
- `cargo update --ignore-rust-version`
This does not include
- `edition = "2024"`
- `resolver = "3"`
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g., `cargo metatada`, status messages,
`SourceID` will display in the v4 URL encoded format.
This shouldn't affect the majority of Rust users,
as `SourceId` representation should be opaque to them,
unless comparing `SourceId` across different version of toolchains.
Fix cargo add behaving different when translating package name
Fixes#13702Fixes#10680
TODOs
- [x] ~Fuzzy match registry dependencies in `cargo remove` as well~
`cargo remove` does not need fuzzy matching, because there is no unexpected behavior for the user
- [x] ~Don't duplicate name permutation generation~
Unsure whether this is worth it
- [ ] Shall we reject cases where multiple different permutations match?
- [x] Add comments that explain the behavior
This expands on #14461 to where only MSRV-compatible versions are
"actionable". MSRV-incompatible versions are therefore unstyled.
We report the MSRV needed so people can choose to unblock by updating
their MSRV. I had wondered if we should report the the absolute latest
MSRV-incompatible version or the one with the next higher MSRV from
where the user is at. Both are reasonable use cases, so I erred with
absolute latest version.
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
Add `--lockfile-path` flag
This change implements a new `--lockfile-path` proposed in #5707 .
Functionality added:
- Add `--lockfile-path <PATH>` to all commands that support `manifest-path` with exception of:
- `locate-project` (doesn't use lock file)
- `verify-project` (is deprecated)
- `read-manifest` (doesn't use lock file)
- Behind -Zunstable-options and docs
- The flag's docs / `--help` has (unstable) in them
- `<PATH>` must end with `Cargo.lock`. If specified path doesn't exist (or parent director(ies), create all the parent directories and the lockfile itself
Implementation TLDR: add `requested_lockfile_path` into `Workspace` and set it on `workspace(gctx)` call (setting from the context)
Update `lockfile.lock_root()` to respect `requested_lockfile_path` (if set)
Add test cases covering all affected commands. Tested creating lockfile, reading lockfile, overriding default (`./Cargo.lock`) lockfile, symlink tests. Extra tests for package to make sure pinned versions from path's lockfile are respected (i.e. double check correct lockfile is used)
I doubt this flag will be used for any command that's not read-only, but I tried to cover all the commands.
fix(toml)!: Disallow source-less dependencies
### What does this PR try to resolve?
This is part of #13629 addressing “dependency without path, version, git, workspace specified”.
This turns deps like
```toml
foo = { optional = true }
```
from `version="*"` deps with a warning into errors. This breaking change was deemed acceptable because this behavior has been considered a bug from the beginning.
We have gotten little to no feedback about people wanting this behavior.
This improves our forwards-compatibility story as we can add new dependency sources and they won't be considered a wildcard registry dependency on older cargo.
### How should we test and review this PR?
I removed the `cargo_add` test because it is redundant.
We no longer get the “unused key” warnings because those warnings get deferred to after this error gets reported.
### Additional information
This is part of #13629
This turns deps like
```toml
foo = { optional = true }
```
from `version="*"` deps with a warning into errors.
This breaking change was deemed acceptable because this behavior has
been considered a bug from the beginning.
We have gotten little to no feedback about people wanting this behavior.
This improves our forwards-compatibility story as we can add new
dependency sources and they won't be considered a wildcard registry
dependency on older cargo.
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.
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 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.
A case the tests showed but isn't covered here is when a `[features]`
table is created, the dependencies-end comment gets attached to that,
e.g. see cargo_add/overwrite_optional
Fixes#13645
feat(add): Fallback to `rustc -v` when no MSRV is set
### What does this PR try to resolve?
#10653 made version-requirement selection respect MSRV as part of #9930.
This updates the implementation for the now-approved RFC specifies that we should respect `rustc -v` if there is no MSRV.
The messages also get a little bit of polish.
### How should we test and review this PR?
Tests are added in separate commits for easier viewing of behavior changes.
### Additional information
