Duplicate major version in lock file causes "failed to select a version"

[kpreid]

Problem

After rebasing one of my old git branches, I ended up with two [[package]] entries in my Cargo.lock file for the same major version. Instead of alerting me that my lock file was invalid, Cargo gave a misleading "failed to select a version" error.

Steps

1. Create a workspace with two packages, foo and bar.

   [package]
   name = "foo"
   version = "0.1.0"
   edition = "2021"
   
   [dependencies]
   paste = "1.0.5"

   [package]
   name = "bar"
   version = "0.1.0"
   edition = "2021"
   
   [dependencies]
   paste = "1.0.12"

2. Trigger Cargo.lock generation.

3. Edit Cargo.lock so that it contains two entries for paste (this is the part that happened automatically via git):

   [[package]]
   name = "paste"
   version = "1.0.5"
   source = "registry+https://github.com/rust-lang/crates.io-index"
   
   [[package]]
   name = "paste"
   version = "1.0.12"
   source = "registry+https://github.com/rust-lang/crates.io-index"

4. Run cargo check or any build command.

This is the error I get:

error: failed to select a version for `paste`.
    ... required by package `bar v0.1.0 (/Users/kpreid/Projects/rust/ws/bar)`
versions that meet the requirements `^1.0.12` (locked to 1.0.12) are: 1.0.12

all possible versions conflict with previously selected packages.

  previously selected package `paste v1.0.5`
    ... which satisfies dependency `paste = "^1.0.5"` (locked to 1.0.5) of package `foo v0.1.0 (/Users/kpreid/Projects/rust/ws/foo)`

failed to select a version for `paste` which could resolve this conflict

Possible Solution(s)

I'm not familiar with the official definition of the lock file format, but empirically, a normal lock file disambiguates by version number all references to a package whenever there are multiple versions of the same package name. This corrupted lock file does not do that, so it is (I assume) definitely invalid and not merely not-what-is-intended.

Cargo could report this problem instead of proceeding, or it could automatically delete the entry with the lower version (since that will probably be the unintended change accidentally merged from an old branch's lock file state). The latter is consistent with what it would do if foo and bar's lock file entries did have versioned references to paste.

Notes

This is similar to #2302, but evidently the fix for that didn't fix this.

Version

cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.87.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.6.5 [64-bit]

Also reproduces with nightly:

cargo 1.71.0-nightly (d0a4cbcee 2023-04-16)
release: 1.71.0-nightly
commit-hash: d0a4cbcee614fdb7ba66e860e603a00a644d71f8
commit-date: 2023-04-16
host: x86_64-apple-darwin
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 7.87.0 (sys:0.4.61+curl-8.0.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1t  7 Feb 2023
os: Mac OS 12.6.5 [64-bit]

[kpreid]

@rustbot label +A-errors

[weihanglo]

That's is indeed a bad message 😞. #1818 is proposal of adding a merge driver but seems like a huge effort.

In practice Cargo should try an auto-fix on it. If it can't fix it then prompt users to how to fix manually. I don't really know how hard it could be to implement the auto-fix, but we could try improving the error message as well as the documentation.

Things I'd suggest for now.

• Add a new entry in Cargo FAQ telling how to resolve a git merge conflict in Cargo.lock. (fixed by Add a description of Cargo.lock conflicts in the Cargo FAQ #12185)
• Cargo could suggest something like "try running cargo generate-lockfile" when a user sees "failed to select a version for <pkg> which could resolve this conflict". We need to make sure the situation is effiectly good and safe to run cargo generate-lockfile though. Not valid.

[weihanglo]

Triage: #12185 made some enhancement around documentation. I wonder if we want to pursue a better error message when duplicate SemVer versions found in lockfile specifically. It should only happen when someone or some tool manually edited it, so this may be a special case than a general resolution failure.

This is not an easy task but the change hitting this is low. I'll put P-low on it for now.