Cargo: Improve the error message for when a patched dependency doesn't resolve to anything

[sunjay]

If you were brought here from an error message: It may be that the version of a dependency in your Cargo.lock file does not match the version of your patched dependency. You can often fix this by running cargo update -p <your package name>. We're working on improving this error message to provide better, more detailed suggestions.

If you ran into this error message because of a different reason with a different solution, please let us know in the comments so we can address it. :)

---

This issue is meant to be a more long term fix than the error message updated in https://github.com/rust-lang/cargo/pull/4607.

From @alexcrichton:

Ideally what we'd do is upon failure do a query again for a more relaxed version constraint, seeing if you just got the wrong version. If that fails we could say that the package doesn't even exist in the source.

More details from @sunjay in the original PR (#4607)

The specific problem that I ran into occurred when I was trying to upgrade the rustfmt submodule in the rust codebase. The rustfmt-nightly dependency changed version numbers and this conflicted with what was in the Cargo.lock file. After some detective work I was able to find the documentation on [patch] which I had never read before and the following relevant paragraphs from some other documentation:

Next up we need to ensure that our lock file is updated to use this new version of uuid so our project uses the locally checked out copy instead of one from crates.io. The way [patch] works is that it'll load the dependency at ../path/to/uuid and then whenever crates.io is queried for versions of uuid it'll also return the local version.

This means that the version number of the local checkout is significant and will affect whether the patch is used. Our manifest declared uuid = "1.0" which means we'll only resolve to >= 1.0.0, < 2.0.0, and Cargo's greedy resolution algorithm also means that we'll resolve to the maximum version within that range. Typically this doesn't matter as the version of the git repository will already be greater or match the maximum version published on crates.io, but it's important to keep this in mind!

If it was not for the person who wrote those docs, I would not have known what to do here!

[kornelski]

I've ran into this for the reason as described (I've patched a package with a local dir, cargo updated, and then checked out an earlier version in the patch's target directory), but the cargo update -p <package> command does not fix it — it displays exactly the same message again.

Only deleting Cargo.lock solves the problem for me.

It's still a bug as of rustc 1.33.0-nightly (e40548bc4 2018-12-21)

[Xanewok]

Encountered this in the exact scenario described by @sunjay, when trying to upgrade rustfmt module in rust repo.
What I did was I upgraded RLS submodule first, which caused Cargo to add

 [[package]]
 name = "rustfmt-nightly"
 version = "0.3.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"

in addition to previously patched, local rustfmt [[package]] with 0.3.2 version.
Then, when I tried to checkout new 0.3.4 version of rustfmt module, I got this error. cargo update -p rustfmt-nightly didn't help.
What I did what was @pornel suggested, but I only deleted the old

 [[package]]
 name = "rustfmt-nightly"
 version = "0.3.2"

entry and this fixed the issue.

[Eh2406]

@alexcrichton did you fix this recently?

[alexcrichton]

@Eh2406 I don't think I purposely did but if it was fixed as a side product that'd be nice! (and if so we should certainly add a test for this)

[stale[bot]]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[sunjay]

This is likely still an issue and it is probably that no one has gotten to it yet.

[jethrogb]

If you got here when trying to compile rustc, make sure to update your submodules: git submodule update --init --recursive

[chinedufn]

If you get here and none of the above works I just ran into this error and fixed it by deleting my Cargo.lock and re-building

[dignifiedquire]

Same issue here, only removing Cargo.lock fixes the issue. (rustc 1.38.0 nightly 2019-08-08)

[Gowee]

I just came back to a library crate I have not touched for months and git pull the remote. cargo update -p foo results in error of bar and vice versa. cargo update w/o any additional args works for me and takes less time than deleting Cargo.lock.