Location of patch information

[kurtlawrence]

Problem

If there are errors in a [patch] entry, it can be hard to locate where the patch was specified.

I work on a large code base that spans multiple workspace crates and cross repo crates.
I have experienced a few times that we migrate a set of dependencies, and get caught with resolution errors. If the error is because of a [patch] entry which is no longer applicable, it only gives the crate name that is failing.
Most of the time we define patches in the workspace Cargo.toml, however there have been occasion to put them into the .cargo/config.toml for various reasons.

The .cargo/config.toml is not a common location to look for patches, it would be helpful if the error message could point to where the patch is being specified.

Proposed Solution

Cargo gives more detail for error messages involving [patch]es. Specifically the location of the [patch] entry would quickly help pinpoint where to fix the issue.

Notes

No response

[epage]

Could you provide reproduction steps for an error, including an example error message?

[kurtlawrence]

I wasn't able to get the ambiguity error I was seeing, but I can trivially produce an error if I specify a patch version that doesn't match:

[patch.crates-io.serde]
git = "https://github.com/serde-rs/serde"
version = "1.0.203"

Error:

    Updating git repository `https://github.com/serde-rs/serde`
error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`

Caused by:
  patch for `serde` in `https://github.com/rust-lang/crates.io-index` failed to resolve

Caused by:
  The patch location `https://github.com/serde-rs/serde` contains a `serde` package with version `1.0.202`, but the patch definition requires `^1.0.203`.
  Check that the version in the patch location is what you expect, and update the patch definition to match.

The main thing that I think is lacking is where the patch is specified:

This would be ideal, but would depend if there is span info available. Otherwise just the location of the TOML file would be useful.

    Updating git repository `https://github.com/serde-rs/serde`
error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`

Caused by:
  patch for `serde` in `https://github.com/rust-lang/crates.io-index` failed to resolve

Caused by:
  The patch location `https://github.com/serde-rs/serde` contains a `serde` package with version `1.0.202`, but the patch definition requires `^1.0.203`.
  Check that the version in the patch location is what you expect, and update the patch definition to match.

Help:
  The patch entry is specified here:
in `.cargo/config.toml`
3 | [patch.crates-io.serde]
4 | git = "https://github.com/serde-rs/serde"
5 | version = "1.0.203"
               ^^^^^^^

[epage]

As I said, could you provide a complete reproduction?

[kurtlawrence]

My apologies

Cargo.toml

[package]
name = "tmp"
version = "0.1.0"
edition = "2021"

[dependencies]
serde = "1"

.cargo/config.toml

[patch.crates-io.serde]
git = "https://github.com/serde-rs/serde"
version = "1.1.0"

src/main.rs

fn main() {
    println!("Hello, world!");
}

[weihanglo]

The error was emitted from this piece of code:

cargo/src/cargo/core/registry.rs

Lines 993 to 1011 in ac8c6ab

	Poll::Ready(Err(if found.is_empty() {
	anyhow::anyhow!(
	"The patch location `{}` does not appear to contain any packages \
	matching the name `{}`.",
	orig_patch.source_id(),
	orig_patch.package_name()
	)
	} else {
	anyhow::anyhow!(
	"The patch location `{}` contains a `{}` package with {}, but the patch \
	definition requires `{}`.\n\
	Check that the version in the patch location is what you expect, \
	and update the patch definition to match.",
	orig_patch.source_id(),
	orig_patch.package_name(),
	found,
	orig_patch.version_req()
	)
	}))

It might be possible to attach a span information with orig_patch, though that would be quite challenging.

• [patch] can be defined in both Carg.toml and Cargo configurations. Currently Cargo has only a rudimentary diagnostics system. It's around the parsing of Cargo.toml at this moment. .cargo/config.toml hasn't yet covered.
• The error is not emitted during parsing those TOML files. It was done during the phase of the dependency resolution preparation. The current diagnostics system is not available in that phase.

[epage]

Not having looked at the code, would it be possible to track any of

• If it came from config or manifest
• Which config
• Which manifest

Those might be smaller steps that could offer most of what is needed here without going to the full extent of tracking spans.