cargo: patch was not used message does not adequately describe reason

Heya, not sure whether we consider usability issues bugs, but, it seemed the closest option.

When configuring [patch]es there are a variety of reasons the patch may not be used, resulting in a message like the following:

warning: Patch `SOMETHING` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.

This gives a list of reasons that can be particularly difficult to debug, as well as the recommendation that cargo update may help, which is particularly helpful when this message is printed by cargo update. As an alternative, it would be great to print the specific reason the [patch] wasn’t used, and a proposed resolution, which I believe is in-line with other compiler error improvements.

Some possible examples:

warning: Patch `SOMETHING` was not used in the crate graph.
Patch version "0.14.0" from `../SOMETHING` does not meet package constraint ">0.15.0",
this may be resolved by updating the `SOMETHING` package version

warning: Patch `SOMETHING` was not used in the crate graph.
Patch version "0.14.0" does not match the package version in Cargo.lock,
this may be resolved by running `cargo update` to update the cargo lock file.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 5
Comments: 17 (9 by maintainers)

Commits related to this issue

Auto merge of #10130 - weihanglo:issue-8690, r=alexcrichton Improve unused patch message when source URLs mismatched Resolves #8690 `Resolve.unused_patches` does not contains info about which sourc... — committed to rust-lang/cargo by bors 3 years ago

Most upvoted comments

right, turns out to be a user error when you have a git dependency and try to patch with [patch.crates-io]… which is documented here. clearly a mistake on my part but, seems like it would be nice to provide a nudge in the right direction?

with an cargo new whatever project and a clone of https://github.com/rust-lang/log in the same directory.

the following works, as expected the crates.io version is replaced with the local version:

[dependencies]
log = "0.4.11"

[patch.crates-io]
log = { path = "./log" }

This does not work, which, perhaps should be obvious if you read [patch.**crates-io**] but, this took me… some weeks 😕

[dependencies]
log = { git = "https://github.com/rust-lang/log" }

[patch.crates-io]
log = { path = "./log" }

and this gives you the classic “not used in the crate graph” warning

warning: Patch `log v0.4.11 (/Users/ryankurte/projects/patch-test/log)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.

the correct approach of course is to:

[dependencies]
log = { git = "https://github.com/rust-lang/log" }

[patch."https://github.com/rust-lang/log"]
log = { path = "./log" }

imo it’d be excellent to have something like:

warning: Patch `log v0.4.11 (/Users/ryankurte/projects/patch-test/log)` was not used in the crate graph.
Crate `log` from "https://github.com/rust-lang/log" was patched from "crates-io", 
you may wish to use `[patch."https://github.com/rust-lang/log"]` to patch the included crate.
See https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section for more details
...

ryankurte on Sep 30, 2020

I personally wouldn’t worry too much about more unusual situations like that. It would be nice to have the information about the original patch definition, but that may be quite difficult to do (since the unused patches are part of Cargo.lock). If it is possible to provide an improvement for more common mistakes, I would focus on that (assuming that is on the easier side of implementation).

ehuss on Nov 26, 2021

@weihanglo There are many reasons why a patch could fail, so I would recommend trying to tackle individual examples instead of going for a general solution. I think the example above about using the wrong source ([patch.crates-io] instead of the git location) shouldn’t be too hard to improve. I would iterate over the unused patches, and then query resolved if it contains anything close to the missing patch (such as looking for a package by name).

Here is an example that does that. That example only works within a single source, so something similar will need to be done inside resolve_with_previous (just look for a package by name, ignoring the source and version).

ehuss on Nov 13, 2021