cargo remove prints "Removing X" for dependencies that never get removed when the command fails

[GuTS805]

Problem

cargo remove prints a "Removing X from dependencies" status line for each dependency before validating whether it exists. If any name in the list is invalid, the whole command fails atomically and nothing is written to Cargo.toml — but the status lines for the valid entries already printed, making it look like they were removed.

Example:

$ cargo remove serde foobar-not-a-dog
    Removing serde from dependencies
    Removing foobar-not-a-dog from dependencies
error: the dependency `foobar-not-a-dog` could not be found in `dependencies`

$ cat Cargo.toml
[dependencies]
serde = "1.0.229"   # unchanged, never removed

Source: src/ops/cargo_remove.rs, the loop prints the "Removing" status (around line 46) before validating/removing the entry (line 48).

Steps

1. cargo new demo && cd demo
2. cargo add serde
3. cargo remove serde foobar-not-a-dog
4. cat Cargo.toml. Serde is still listed despite the "Removing serde" line

Possible Solution(s)

Validate all dependency names against the target table before printing any "Removing" status lines, or only print the status after the removal actually succeeds.

Notes

Not the same as #16499 (about the error message wording) or #16781 (name normalization).Neither addresses this status-vs-atomicity mismatch.

Version

cargo 1.97.1 (c980f4866 2026-06-30)
release: 1.97.1
commit-hash: c980f4866141969fab6254a680546a277789d6f0
commit-date: 2026-06-30
host: x86_64-pc-windows-msvc
libgit2: 1.9.2 (sys:0.20.4 vendored)
libcurl: 8.20.0-DEV (sys:0.4.88+curl-8.20.0 vendored ssl:Schannel)
os: Windows 10.0.26200 (Windows 11 CoreSingleLanguage) [64-bit]

[epage]

Could you help me understand why you see this as a problem?

For me, it is saying “Removing", not “Removed", so it isn't committed to the result and having an error during the process seems reasonable for nothing to have changed.

[GuTS805]

I think what actually tripped me up was that with multiple dependencies, the status lines for both entries look identical whether they end up applied or not, so it briefly reads like a partial success rather than an all or nothing rollback. But I agree that's more about the format not signaling "this whole batch is atomic" than the "Removing" wording itself being wrong. Happy to close this if you don't see value in changing it.

[GuTS805]

No rush.
Just wanted to bump this in case it slipped through. Whenever you're free, let me know either way.