[patch] with duplicate values causes panic

[ehuss]

Problem
A [patch] table with multiple values using package can cause a panic.

[package]
name = "foo"
version = "0.1.0"
edition = "2018"

[dependencies]
bitflags = "1.0"

[patch.crates-io]
bitflags = {git="https://github.com/bitflags/bitflags.git"}
bitflags2 = {git="https://github.com/bitflags/bitflags.git", package="bitflags"}

Results in:

    Updating git repository `https://github.com/bitflags/bitflags.git`
thread 'main' panicked at 'assertion failed: remaining.next().is_none()', src/tools/cargo/src/cargo/core/registry.rs:648:13
stack backtrace:
   0: std::panicking::default_hook::{{closure}}
   1: std::panicking::default_hook
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::begin_panic
   4: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   5: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
   6: cargo::core::summary::Summary::map_dependencies
   7: cargo::core::registry::lock
   8: cargo::ops::resolve::resolve_with_previous
   9: cargo::ops::resolve::resolve_with_registry
  10: cargo::ops::resolve::resolve_ws_with_method
  11: cargo::ops::cargo_compile::compile_ws
  12: cargo::ops::cargo_compile::compile
  13: cargo::commands::build::exec
  14: cargo::cli::main
  15: cargo::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
  18: __rust_maybe_catch_panic
  19: std::rt::lang_start_internal
  20: main

Notes

This appears to happen ever since package renaming was introduced up to latest nightly-2019-08-19.

Obviously you shouldn't have two patches to the same location, but it shouldn't panic.

[Hoverbear]

Confirmed I hit this when testing #7263 :

log-0-3-9-use-static-module = { package = "log", git = "https://github.com/busyjay/log", branch = "use-static-module" }
log-0-4-6-revert-to-static = { package = "log", git = "https://github.com/busyjay/log", branch = "revert-to-static" }

[cbeck88]

Why shouldn't you have 2 patches to the same location? It seems like it could work -- maybe you need two versions of same code without feature unification?

I could always fork the repo a second time without changes, and then it would be expected to work, right?