nightly panicked at 'assertion failed: directive.imported_module.get().is_none()'

[Boscop]

thread 'main' panicked at 'assertion failed: directive.imported_module.get().is_none()', src\librustc_resolve\resolve_imports.rs:867:17
stack backtrace:
   0: std::sys_common::alloc::realloc_fallback
   1: std::panicking::take_hook
   2: std::panicking::take_hook
   3: rustc::ty::structural_impls::<impl rustc::ty::context::Lift<'tcx> for rust
c::ty::instance::InstanceDef<'a>>::lift_to_tcx
   4: std::panicking::rust_panic_with_hook
   5: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b, 'cl>
 as syntax::visit::Visitor<'a>>::visit_ty
   6: rustc_resolve::resolve_imports::ImportResolver::finalize_imports
   7: rustc_resolve::Resolver::resolve_crate
   8: rustc_driver::driver::build_output_filenames
   9: rustc_driver::driver::count_nodes
  10: rustc_driver::driver::compile_input
  11: rustc_driver::run_compiler
  12: rustc_driver::driver::build_output_filenames
  13: rustc_driver::run_compiler
  14: <humantime::duration::Error as std::error::Error>::cause
  15: _rust_maybe_catch_panic
  16: rustc_driver::profile::dump
  17: rustc_driver::main
  18: <unknown>
  19: std::panicking::update_panic_count
  20: _rust_maybe_catch_panic
  21: std::rt::lang_start_internal
  22: <unknown>
  23: <unknown>
  24: BaseThreadInitThunk
  25: RtlUserThreadStart
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 (00e03ee57 2018-11-22) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

It used to build with an older nightly.
Any idea how I can get it to build again?

[petrochenkov]

src\librustc_resolve\resolve_imports.rs:867:17

Hmm, this should be different from #56125 according to the line number.

@Boscop
Could you give some minimized reproduction?
Before adding this assert I tried to construct a case where it would be hit, but couldn't.

[Boscop]

@petrochenkov

In my rust-toolchain file I have nightly-2018-11-23. When I change it to nightly-2018-11-20 it also panics but not with e.g. nightly-2018-10-31, there it doesn't panic but shows this error:

error: `actix` import is ambiguous
 --> src\db.rs:2:5
  |
2 | use actix::prelude::*;
  |     ^^^^^------------
  |     |
  |     can refer to external crate `::actix`
  |     may refer to `self::actix` in the future
  |
  = help: write `::actix` or `self::actix` explicitly instead
  = note: in the future, `#![feature(uniform_paths)]` may become the default

Btw, this project is also doing use actix::prelude::*; in 2 places, and using edition 2018. So maybe it is related to the other issue?

[petrochenkov]

@Boscop
I know where exactly this assert is in rustc, when it was introduced and how it's related to the other issues, but I cannot fix this without a code snippet reproducing the ICE.

[Boscop]

@petrochenkov After I changed the import to use ::actix::prelude::*; it builds fine with nightly-2018-11-23, too. So I think the issue is the same as #56125 and the minimal example crate would also be the same: https://github.com/tmpolaczyk/actix_ice

[petrochenkov]

If this is https://github.com/tmpolaczyk/actix_ice, then it should be already fixed in #56147.
I'll check again.

[petrochenkov]

https://github.com/tmpolaczyk/actix_ice is indeed fixed and the fix has reached nightly, so this is a separate issue (as I suspected from the line number in the ICE), in this case reproduction is still needed.

[petrochenkov]

I still cannot reproduce this and from code I don't understand how that assert (

rust/src/librustc_resolve/resolve_imports.rs

Line 867 in edaac35

assert!(directive.imported_module.get().is_none());

) can possibly fire.

Denominating from Rust 2018 Release, but keeping it open for now in case @Boscop comes up with a working reproduction.

[petrochenkov]

Reproduced and fixed in #56206