Support [patch] in .cargo/config files

[jonhoo]

This patch adds support for [patch] sections in .cargo/config.toml
files. Patches from config files defer to [patch] in Cargo.toml if
both provide a patch for the same crate.

The current implementation merge config patches into the workspace
manifest patches. It's unclear if that's the right long-term plan, or
whether these patches should be stored separately (though likely still
in the manifest). Regardless, they should likely continue to be
parsed when the manifest is parsed so that errors and such occur in the
same place regardless of where a patch is specified.

Fixes #5539.

[rust-highfive]

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

I'm a bit wary about modifying the patch tables so deep in the manifest, it seems like this would emulate a [patch] in all crates.io dependencies decoded as well I think? Would it be possible to refactor so that when the [patch] entries are registered with the registry that's where the config-based patches are registered?

[jonhoo]

Good point! I placed the parsing there because I wanted to re-use to_dependency, which takes a Context, which is only constructed in that scope. I've re-organized slightly in 140a770 so that the parsing still happens in the same place (where we have Config), but the actual merging of dependencies only happens on resolve. What do you think?

I'm also a little unsure about

cargo/src/cargo/core/workspace.rs

Lines 394 to 398 in 140a770

	for dep in &mut *deps {
	if let Some(i) = left.iter().position(|cdep| {
	// XXX: should this also take into account version numbers?
	dep.name_in_toml() == cdep.name_in_toml()
	}) {

The patch tables are stored as BTreeMap<String, BTreeMap<String, TomlDependency>> which implies that each key in the patch table has to be unique, but I'm concerned about what happens if someone tries to patch, say, two versions of the same package using different patch names:

# Cargo.toml
[patch.crates-io]
nom5 = { ..., version = "5" }
nom6 = { ..., version = "6" }

# .cargo/config
[patch.crates-io]
nom = { ..., version = "5" }

Can that even happen? What's the expected outcome in this case?

[bors]

☔ The latest upstream changes (presumably #9181) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #8825) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Apologies for the delay, but this version looks good to me! Ia've got some minor thoughts inline, but otherwise r=me

[jonhoo]

@alexcrichton Excellent, all good comments — I've pushed fixes in b50cde8. I don't think bors picked up your r= though?

[alexcrichton]

@bors: r+

Oh that's not an actual feature of bors, it's more of "I won't take XX days to review this next time, I'll write r+ soon after I see the email it was updated"

[bors]

📌 Commit b50cde8 has been approved by alexcrichton

[bors]

⌛ Testing commit b50cde8 with merge 695465c...

[bors]

☀️ Test successful - checks-actions
Approved by: alexcrichton
Pushing 695465c to master...

[ehuss]

@jonhoo Can you follow up with a PR to add this to the unstable documentation (here). Unstable features should always be documented there.

[jonhoo]

Will do! Should we leave this open as a tracking issue? What do you envision as the stabilization path for this feature?

[ehuss]

I think it's fine to open a new issue, it doesn't matter too much. The "new issue" button should have a template for a tracking issue.

[ehuss]

Oh, and I'm not sure exactly what needs to happen to stabilize. We don't have a clear process for that, since it doesn't happen too often. 😜 Normally we let it bake on nightly for a while, to let people to try it out and see if there are any issues, and to gain more experience with it. This also gives some time to consider if it is the right design and something that we actually want to commit to.

[jonhoo]

Documentation PR: #9270

Tracking issue: #9269