patch was not used message does not adequately describe reason

[ryankurte]

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.

Related to: #8400

[jyn514]

This is a cargo bug, not a rust bug.

[jyn514]

@ehuss could you transfer the issue?

[ehuss]

Transferred.

@ryankurte it would be helpful if you could put together an example that doesn't print a helpful error message. Please also include which version of Cargo you are using. The messages were improved recently (#8248), and the example where the patch does not satisfy the dependency requirement should say something like this:

[ERROR] failed to resolve patches for `https://github.com/rust-lang/crates.io-index`
Caused by:
  patch for `bar` in `https://github.com/rust-lang/crates.io-index` failed to resolve
Caused by:
  The patch location `[..]/foo/bar` contains a `bar` package with version `0.1.0`, 
  but the patch definition requires `^0.1.1`.
  Check that the version in the patch location is what you expect, and update the 
  patch definition to match.

[ryankurte]

oh hey that's super exciting, maybe this is solved (though i am still seeing the old messages on 1.48.0-nightly?)

it would be helpful if you could put together an example that doesn't print a helpful error message

the current iteration of this is in a non-public project and, (having seen / resolved this many a time prior) i have no idea why the resolution is broken in this case, which is a bit of an impediment to useful reproduction :-( i will try to dig further.

[ryankurte]

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
...

[ehuss]

Thanks for digging into that! Yea, that definitely seems like a scenario that could stand to have a better error message.

[matu3ba]

@ryankurte

Just writing a requirement list would be easier to read in the documentation.
Does this mean that I am forced to 1. either specify dependencies on git repos in [dependencies], 2.clone crates locally for usage (patching) or 3.only specify branches of the git repo in crates.io ?
The text feels very verbose, but leaves out the important parts.

Using the example

[dependencies]
uuid = "1.0.1"
[patch.crates-io]
uuid = { git = 'https://github.com/uuid-rs/uuid' }

or using uuid ="1.0.0" resulted in the same confusing message.
This kind of problem was abit more frequently asked.

[matu3ba]

My guess is that also the minor version 1.0.1 is significant, but this is not documented.

[ryankurte]

it appears that uuid does not have a version 1.0.0? maybe the example could be updated to something that works?

that said, i would suspect the similar situation is because git targets can't resolve -versions-, so you'd need to also supply a branch or tagargument that contains a compatible version of the crate to patch?

[skhameneh]

I ran into this issue with a slightly different problem, when the major does not match, the patch is ignored. This is not desired behavior as I do not see a way to control the patch apply/ignore logic.