Handle activation conflicts for [patch] sources

[alexcrichton]

This commit updates the resolver to ensure that it recognizes conflicts
when [patch] is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when [patch] was used.
This meant that when you used [patch] it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of [patch]!

The fix here is to catch this use case happening, when a Dependency
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.

Closes #7117

[rust-highfive]

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @Eh2406

[Eh2406]

This makes sense and seems like a good solution for the currently stable functionality. I suspect that there are going to be related bugs with Public and Private dependencies, but that is not stable so we can deal with it then. Similarly this patch case will be a reliable source of complicated resolver bugs on all interesting changes to the resolver so I added it to the list of thing we should someday fuzz test.

One of the things that makes patch feel more reliable than replace is that the resolver basically has no special code for handling it. I wonder if there is any way to fix this bug without adding special handling? I fear that over time we will find more coroner cases this interacts with, not that I can think of any at the moment.

I also am not sure why things don't work with the replace case. Is it just because flag_activated is already called for both versions, so we don't need parent to double insert? Given that the documentation for the replace section does not say that it is deprecated I feel that it is not yet appropriate to put it on "life support".

[alexcrichton]

Yeah that was one of the things about [patch] I also really liked how it turned out, how little it touched the resolver.

I was having a tough time coming up with solutions to this that didn't touch the resolver much though. One idea I had was to have a sort of "shadow resolution graph" which the resolver operates over but then a "real resolution graph" that's handed to the rest of Cargo. This shadow graph would "lie" and say that [patch] crates come from the source that's being patched (not the actual source of the crate itself) but the real resolution graph would say it comes from the real source. This seemed like a pretty invasive solution though and the one here was more targeted. I'm curious though if you've got other ideas on how to possibly solve this, because I'm out of ideas :(

As for replace, TBH I didn't really investigate it that much. It caused panics in the test suite pretty easily by not passing in None (and passing in parent). Remember though that documentation doesn't always reflect reality! The [replace] feature AFAIK hasn't received any support or bugfixes in years now at this point, which is defacto "on life support" even if not explicitly stated in my mind at least

[Eh2406]

I wish I had better ideas. Your idea for a "shadow resolution graph" sounds similar to what we do for replace currently; I wonder if we could have dep_cache do the check for the same source and treat it like a replace if they differ. But if we don't have a better solution then this is good.

[alexcrichton]

Hm maybe? I'm not really sure what you mean though and how that would work. It would also still involve changing the resolver in one way or another as opposed to staying out of the resolver like [patch] basically does today.

[Eh2406]

I'm not really sure what you mean though

I spent some time trying this. The idea does not work with the way replace currently works. Sorry for the noize.

I hope someday we can find a shared abstraction for [patch] and [replace]. But this works so.

@bors r+

[bors]

📌 Commit 83bb30c has been approved by Eh2406

[bors]

⌛ Testing commit 83bb30c with merge 0dd7c50...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: Eh2406
Pushing 0dd7c50 to master...