### What does this PR try to resolve?
This PR fixes a bug where `cargo add` breaks symlinks to Cargo.toml
files. Currently, when Cargo.toml is a symlink and `cargo add` is used
to add a dependency, the symlink is replaced with a regular file,
breaking the link to the original target file.
This issue was reported in #15241 where a user who relies on symlinked
Cargo.toml files found that `cargo add` breaks their workflow.
Fixes#15241
### How should we test and review this PR?
I've modified `LocalManifest::write()` to check if the path is a
symlink, and if so, follow it to get the actual target path. This
ensures we write to the actual file rather than replacing the symlink.
I've also added a test in `tests/testsuite/cargo_add/symlink.rs` that:
1. Creates a symlinked Cargo.toml file
2. Runs `cargo add` to add a dependency
3. Verifies the symlink is preserved and the dependency is added to the
target file
I've manually tested this fix and confirmed it works correctly.
- Preserve symlinks when writing files atomically in write_atomic()
- Update test to verify correct symlink preservation behavior
- Apply rustfmt formatting
This fixes the issue where cargo add would replace symlinked Cargo.toml
files with regular files, breaking the symlink to the original target.
Fixes#15241
This test shows the current behavior where cargo add replaces
symlinked Cargo.toml files with regular files. The test passes,
documenting this problematic behavior.
### What does this PR try to resolve?
Fixes#15436
### How should we test and review this PR?
There are 3 tests for each test case:
- there are no feature suggestions
- there's only one feature suggestion (most common)
- there are several feature suggestions
Stop a few tests which aren't marked with `public_network_test` from
trying to access crates.io. While doing so, also make sure that other
`cargo_add` and `cargo_info` tests initialize the registry.
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.
