Erratic behavior, when [patch]ing Git dependencies

[hannobraun]

I've encountered some erratic behavior when [patch]ing Git dependencies, when the patched crate is depended on using different Git URLs. All of this is a bit involved, so I don't expect anyone to understand the issue by reading my previous sentence. Please bear with me, I have a full example.

Here's my dependency graph (all dependencies are Git dependencies):

The following details are important:

1. Both cargo-patch-test and cargo-patch-test-other-dependency depend on cargo-test-patch-dependency via https://github.com/hannobraun/cargo-patch-test-original-dependency .
2. They don't do so using the same URL. cargo-patch-test has a ".git" at the end of the dependency URL, cargo-patch-test-other-dependency hasn't.
3. cargo-patch-test overrides its dependency on cargo-test-patch-dependency using [patch], switching it to https://github.com/hannobraun/cargo-patch-test-override-dependency.git .
4. cargo-patch-test will fail to build when depending on the original repository, but will work when depending on the overriding repository.

I believe the slightly different URLs are what confuses Cargo and lead to the erratic behavior I'm about to describe.

You can follow along at home by checking out the repository:

git clone https://github.com/hannobraun/cargo-patch-test.git
cd cargo-patch-test

So here's what happens when I try to test cargo-patch-test:

$ cargo test
   Compiling cargo-patch-test v0.1.0 (file:///home/hanno/tmp/Projects/cargo-patch-test)
error[E0369]: binary operation `==` cannot be applied to type `cargo_patch_test_dependency::Container<()>`
  --> src/lib.rs:12:9
   |
12 |         assert_eq!(container, Container(()));
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: an implementation of `std::cmp::PartialEq` might be missing for `cargo_patch_test_dependency::Container<()>`
   = note: this error originates in a macro outside of the current crate

error: aborting due to previous error

error: Could not compile `cargo-patch-test`.

To learn more, run the command again with --verbose.

It fails to compile, because the [patch] section has no effect (if it's working for you, just try again). Let's run cargo update to see if that helps.

$ cargo update
    Updating git repository `https://github.com/hannobraun/cargo-patch-test-original-dependency.git`
    Updating git repository `https://github.com/hannobraun/cargo-patch-test-other-dependency.git`
    Removing cargo-patch-test-dependency v0.1.0 (https://github.com/hannobraun/cargo-patch-test-original-dependency#5a0e05c0)
      Adding cargo-patch-test-dependency v0.1.0 (https://github.com/hannobraun/cargo-patch-test-original-dependency.git#5a0e05c0)
      Adding cargo-patch-test-dependency v0.1.0 (https://github.com/hannobraun/cargo-patch-test-override-dependency.git#d8aedd68)

Looks weird, but ok. Let's try again.
(Update (2018-09-20): Cargo output looks different now, and is not always the same.)

$ cargo test
   Compiling cargo-patch-test-other-dependency v0.1.0 (https://github.com/hannobraun/cargo-patch-test-other-dependency.git#437a9c5a)
   Compiling cargo-patch-test v0.1.0 (file:///home/hanno/tmp/Projects/cargo-patch-test)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44 secs
     Running target/debug/deps/cargo_patch_test-80ebc8a0f35c4a21

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests cargo-patch-test

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

It works! But will it work a second time?
(Update (2018-09-20): cargo update no longer fixes the problem for one build. The only time it works for me is for the first build after git clone. Neither cargo update, nor cargo clean, nor rm -rf target fix the problem for me, which is even weirder.)

$ cargo test
    Updating git repository `https://github.com/hannobraun/cargo-patch-test-original-dependency`
   Compiling cargo-patch-test-other-dependency v0.1.0 (https://github.com/hannobraun/cargo-patch-test-other-dependency.git#437a9c5a)
   Compiling cargo-patch-test v0.1.0 (file:///home/hanno/tmp/Projects/cargo-patch-test)
error[E0369]: binary operation `==` cannot be applied to type `cargo_patch_test_dependency::Container<()>`
  --> src/lib.rs:12:9
   |
12 |         assert_eq!(container, Container(()));
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: an implementation of `std::cmp::PartialEq` might be missing for `cargo_patch_test_dependency::Container<()>`
   = note: this error originates in a macro outside of the current crate

error: aborting due to previous error

error: Could not compile `cargo-patch-test`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Nope! It keeps failing from here on out, until I run cargo update again.
(Update (2018-09-20): It keeps failing from here on out. cargo update no longer helps. Only deleting the repository and cloning it again fixes the problem, but only for the first build after the clone.)

[alexcrichton]

Hm this is indeed quite odd! I'm not quite sure what's happening here just yet, but I was indeed able to reproduce!

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[hannobraun]

I can still reproduce the issue, although there are some variations from the original description. I've added updates to my original comments to describe what I'm seeing now.

[epage]

At this point, someone needs to investigate why and what might be done to fix this.