Closed
Description
Attempting to compile this code fails:
mod some_module {
mod foo {
pub struct x;
}
pub mod bar {
#[allow(unused_imports)]
pub(in super::super) use super::foo::{x};
}
}
fn main(){}
In the playground in nightly(rustc 1.32.0-nightly (f37247f 2018-11-17) haven't tested in previous ones) it causes this error:
Compiling playground v0.0.1 (/playground)
thread 'main' panicked at 'librustc/hir/map/hir_id_validator.rs:31:
ItemLocalIds not assigned densely in ::some_module[0]::bar[0]::{{?}}[0]. Max ItemLocalId = 5, missing IDs = ["[local_id: 1, node:unknown node (id=19)]", "[local_id: 2, node:path segment super (id=17)]", "[local_id: 3, node:path segment super (id=18)]"]; seens IDs = ["(NodeId(16) use some_module::bar::{{?}} (id=16))", "(NodeId(22) path segment foo (id=22))", "(NodeId(21) path segment super (id=21))"]
HirIdValidator: The recorded owner of path segment super (id=17) is ::some_module[0]::bar[0]::{{?}}[0] instead of ::some_module[0]::bar[0]::{{?}}[1]
HirIdValidator: The recorded owner of path segment super (id=18) is ::some_module[0]::bar[0]::{{?}}[0] instead of ::some_module[0]::bar[0]::{{?}}[1]
HirIdValidator: Same HirId ::some_module[0]::bar[0]::{{?}}[1]/2 assigned for nodes path segment super (id=17) and path segment foo (id=31)
HirIdValidator: Same HirId ::some_module[0]::bar[0]::{{?}}[1]/3 assigned for nodes path segment super (id=18) and path segment x (id=23)', librustc/util/bug.rs:47:26
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at libstd/sys_common/backtrace.rs:59
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:480
6: std::panicking::begin_panic
7: rustc::util::bug::opt_span_bug_fmt::{{closure}}
8: rustc::ty::context::tls::with_opt::{{closure}}
9: rustc::ty::context::tls::with_context_opt
10: rustc::ty::context::tls::with_opt
11: rustc::util::bug::opt_span_bug_fmt
12: rustc::util::bug::bug_fmt
13: rustc::hir::map::hir_id_validator::check_crate
14: rustc::hir::map::map_crate
15: rustc::util::common::time
16: rustc_driver::driver::compile_input
17: rustc_driver::run_compiler_with_pool
18: <scoped_tls::ScopedKey<T>>::set
19: rustc_driver::run_compiler
20: syntax::with_globals
21: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
22: rustc_driver::run
23: rustc_driver::main
24: std::rt::lang_start::{{closure}}
25: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
26: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
27: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:398
at libstd/rt.rs:58
28: main
29: __libc_start_main
30: <unknown>
query stack during panic:
end of query stack
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.32.0-nightly (f37247f88 2018-11-17) running on x86_64-unknown-linux-gnu
note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib
note: some of the compiler flags provided by cargo are hidden
It works fine if I replace the list of reexports with reexporting the item by itself:
pub(in super::super) use super::foo::x;