Package version conflict after changing features of dependency

[hasezoey]

Problem

In my current project, i tried upgrading clap to the latest version and enabling a feature (which enabled dependencies), but it turned out that doing this somehow made a conflict:

error: failed to select a version for `proc-macro2`.
    ... required by package `clap_derive v3.0.0`
    ... which satisfies dependency `clap_derive = "^3.0.0"` of package `clap v3.0.9`
    ... which satisfies dependency `clap = "^3.0.9"` (locked to 3.0.9) of package `yt-downloader-rust v0.4.0 (/mnt/projects/rust/yt-downloader)`
versions that meet the requirements `^1.0.28` are: 1.0.36, 1.0.35, 1.0.34, 1.0.33, 1.0.32, 1.0.31, 1.0.30, 1.0.29, 1.0.28

all possible versions conflict with previously selected packages.

  previously selected package `proc-macro2 v1.0.26`
    ... which satisfies dependency `proc-macro2 = "^1.0.20"` (locked to 1.0.26) of package `quote v1.0.9`
    ... which satisfies dependency `quote = "^1.0.9"` (locked to 1.0.9) of package `clap_derive v3.0.0`
    ... which satisfies dependency `clap_derive = "^3.0.0"` of package `clap v3.0.9`
    ... which satisfies dependency `clap = "^3.0.9"` (locked to 3.0.9) of package `yt-downloader-rust v0.4.0 (/mnt/projects/rust/yt-downloader)`

failed to select a version for `proc-macro2` which could resolve this conflict

Note: i know that the mentioned project's commit has some compiler warnings and errors (noticed after deleting Cargo.lock)

Steps

Reproduction:

• clone repository (https://github.com/hasezoey/yt-downloader-rust)
• checkout to commit 309d77a1a8b7812ef730a7c974512160679b88ac
• build once (cargo build --all)
• open Cargo.toml and replace feature yaml with derive for dependency clap
• try to build (cargo build --all)

Possible Solution(s)

The workaround for now is to delete Cargo.toml and run cargo build --all and everything suddenly is resolved

Notes

i tried searching for a possible already existing issue, but i dont quite know what terms to search for

Original issue i had in claps repository: clap-rs/clap#3307

Version

cargo 1.58.0 (7f08ace4f 2021-11-24)
release: 1.58.0
commit-hash: 7f08ace4f1305de7f3b1b0e2f765911957226bd4
commit-date: 2021-11-24
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: Manjaro 21.2.1 (Qonos) [64-bit]

[alexcrichton]

Thanks for the report, and the reproduction! I think that this is a known longstanding bug in Cargo's resolver, unfortunately. Cargo's attempt to use the previous lock file as the source of how to perform version resolution is a bit too strict here and simply requires that the old version in the lock file must be used, when in fact it should be updated to account for the incremental edit to the manifest.

I've talked with @Eh2406 in the past about fixing this along the lines of where the resolver today "locks" to various versions but it shouldn't do that, instead simply preferring whatever is in Cargo.lock and if that all happens to work then great, otherwise other versions are used due to edits. I believe such an architecture would fix this issue but neither of us has unfortunately had time to get around to implementing that.

[ta32]

Another work around:
I added proc-macro2 = "1.0.28"
to the cargo.toml and it built everything again. Then after I removed it there is no issue.
cargo 1.63.0

[hammypants]

To anyone digging around and hits something like this a few years later, the workaround described by ta32 still works.