ICE when using rename-dependency with a crate that is also a transitive dependency

[kazcw]

Testing with a recent nightly (60efbde 2018-06-23), importing a crate a by a rename-dependency alias (rust-lang/cargo#5422) before importing a crate b that also depends on a causes an compiler panic.

I've put together a minimal workspace demonstrating the crash. Here are the highlights:

c/Cargo.toml:

cargo-features = ["rename-dependency"]
[dependencies]
not_a = { path = "../a", package = "a" }
b = { path = "../b" }

c/src/lib.rs:

extern crate not_a;
extern crate b; // depends on a

backtrace when compiling c:

thread 'main' panicked at 'assertion failed: locate_ctxt.hash.is_none()', librustc_metadata/creader.rs:352:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
   7: rustc_metadata::cstore::CStore::iter_crate_data
   8: rustc_metadata::creader::CrateLoader::load
   9: rustc_metadata::creader::CrateLoader::resolve_crate
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: rustc_metadata::creader::CrateLoader::resolve_crate
  13: <rustc_metadata::creader::CrateLoader<'a> as rustc::middle::cstore::CrateLoader>::process_extern_crate
  14: rustc_resolve::build_reduced_graph::<impl rustc_resolve::Resolver<'a>>::build_reduced_graph_for_item
  15: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item
  16: syntax::visit::walk_item
  17: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item
  18: syntax::ext::expand::Expansion::visit_with
  19: rustc_resolve::macros::<impl syntax::ext::base::Resolver for rustc_resolve::Resolver<'a>>::visit_expansion
  20: syntax::ext::expand::MacroExpander::collect_invocations
  21: syntax::ext::expand::MacroExpander::expand
  22: syntax::ext::expand::MacroExpander::expand_crate
  23: rustc_driver::driver::phase_2_configure_and_expand_inner::{{closure}}
  24: rustc::util::common::time
  25: rustc_driver::driver::phase_2_configure_and_expand
  26: rustc_driver::driver::compile_input
  27: rustc_driver::run_compiler_with_pool
  28: <scoped_tls::ScopedKey<T>>::set
  29: syntax::with_globals
  30: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  31: __rust_maybe_catch_panic
  32: rustc_driver::run
  33: rustc_driver::main
  34: std::rt::lang_start::{{closure}}
  35: std::panicking::try::do_call
  36: __rust_maybe_catch_panic
  37: std::rt::lang_start_internal
  38: main
  39: __libc_start_main
  40: <unknown>
query stack during panic:
end of query stack

Note that if I extern crate the dependent crate before renamed crate, every is dandy.

This is likely the same bug as #51259, but I have found a minimal test case.

[withoutboats]

I also encountered this bug while trying to use this feature. This is possibly a blocker on the 2018 edition; if rename-dependency can't be stabilized the new module system will have a UX regression.

[withoutboats]

Did some investigation:

This happens if & and only if you rename a dependency that you have a transitive dependency on as well.

It does not matter if your dependency that is also dependent on the renamed crate renames it itself or not, only that this crate you've renamed is also a transitive dependency.

I've renamed the issue accordingly.

[aturon]

cc @rust-lang/cargo

[alexcrichton]

I believe this is fixed in #52723