Closed
Description
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.