ICE: "to_immediate: expected Operand::Immediate, got Indirect"

[jerous86]

I'm trying to compile a personal project, but the compiler crashes with the following message:
error: internal compiler error: librustc_mir/interpret/operand.rs:129: to_immediate: expected Operand::Immediate, got Indirect(MemPlace { ptr: Ptr(Pointer { alloc_id: AllocId(14642), offset: Size { raw: 0 } }), align: Align { abi_pow2: 2, pref_pow2: 2 }, extra: None })

I have no idea how to isolate the code that triggers this compiler error, as it's a medium-sized project. Last time I compiled it (and then it compiled successfully) was around beginning of June.

I have the error with nightly and beta.

Meta

Notes from cargo:

• note: rustc 1.30.0-beta.7 (0ebb250 2018-09-22) running on armv7-unknown-linux-gnueabihf
• note: compiler flags: -C opt-level=3 --crate-type bin
• note: some of the compiler flags provided by cargo are hidden

Backtrace of RUST_BACKTRACE=1 cargo build --release

error: internal compiler error: librustc_mir/interpret/operand.rs:129: to_immediate: expected Operand::Immediate, got Indirect(MemPlace { ptr: Ptr(Pointer { alloc_id: AllocId(14642), offset: Size { raw: 0 } }), align: Align { abi_pow2: 2, pref_pow2: 2 }, extra: None })

thread 'main' panicked at 'Box', librustc_errors/lib.rs:586:9
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
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             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:481
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::bug_fmt
  14:  as rustc::mir::visit::Visitor<'tcx>>::visit_terminator_kind
  15: ::run_pass
  16: rustc_mir::transform::optimized_mir::{{closure}}
  17: rustc_mir::transform::optimized_mir
  18: rustc::ty::query::__query_compute::optimized_mir
  19: rustc::ty::query:: for rustc::ty::query::queries::optimized_mir<'tcx>>::compute
  20: rustc::dep_graph::graph::DepGraph::with_task_impl
  21: rustc::ty::context::tls::with_related_context
  22: rustc::ty::query::plumbing::>::force_query_with_job
  23: rustc::ty::query::plumbing::>::try_get_query
  24: rustc::ty::>::instance_mir
  25: rustc_mir::monomorphize::collector::collect_items_rec
  26: rustc_mir::monomorphize::collector::collect_items_rec
  27: rustc_mir::monomorphize::collector::collect_items_rec
  28: rustc_mir::monomorphize::collector::collect_items_rec
  29: rustc_mir::monomorphize::collector::collect_items_rec
  30: rustc_mir::monomorphize::collector::collect_items_rec
  31: rustc_mir::monomorphize::collector::collect_items_rec
  32: rustc_mir::monomorphize::collector::collect_items_rec
  33: rustc_mir::monomorphize::collector::collect_items_rec
  34: rustc_mir::monomorphize::collector::collect_items_rec
  35: rustc_mir::monomorphize::collector::collect_items_rec
  36: rustc_mir::monomorphize::collector::collect_items_rec
  37: rustc_mir::monomorphize::collector::collect_items_rec
  38: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
  39: rustc::util::common::time
  40: rustc_mir::monomorphize::collector::collect_crate_mono_items
  41: rustc::util::common::time
  42: rustc_codegen_llvm::base::collect_and_partition_mono_items
  43: rustc::ty::query:: for rustc::ty::query::queries::collect_and_partition_mono_items<'tcx>>::compute
  44: rustc::dep_graph::graph::DepGraph::with_task_impl
  45: rustc::ty::context::tls::with_related_context
  46: rustc::ty::query::plumbing::>::force_query_with_job
  47: rustc::ty::query::plumbing::>::get_query
  48: rustc_codegen_llvm::base::codegen_crate
  49: ::codegen_crate
  50: rustc::util::common::time
  51: rustc_driver::driver::phase_4_codegen
  52: rustc_driver::driver::compile_input::{{closure}}
  53: rustc::ty::context::tls::enter_context
  54: >::with
  55: rustc::ty::context::TyCtxt::create_and_enter
  56: rustc_driver::driver::compile_input
  57: rustc_driver::run_compiler_with_pool
  58: rustc_driver::driver::spawn_thread_pool
  59: rustc_driver::run_compiler
  60: >::set
  61: syntax::with_globals
  62: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  63: rustc_driver::run
  64: rustc_driver::main
  65: std::rt::lang_start::{{closure}}
  66: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  67: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  68: std::panic::catch_unwind
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
  69: std::rt::lang_start_internal
             at libstd/rt.rs:58
  70: main
  71: __libc_start_main
query stack during panic:
#0 [optimized_mir] processing `medium::Medium::cmp`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: aborting due to previous error

[cramertj]

I have the error with nightly and beta.

Does this mean that you do not see the error on stable? Are you able to provide a test case?

[jerous86]

Sorry, I hadn't tested yet with stable. I just did, and with stable (rustc 1.29.0 (aa3ca19 2018-09-11) running on armv7-unknown-linux-gnueabihf) it also crashes, but now giving a different compiler error:

error: internal compiler error: librustc_mir/transform/const_prop.rs:619: const index not primitive: (ByRef(Ptr(Pointer { alloc_id: AllocId(12268), offset: Size { raw: 0 } }), Align { abi_pow2: 2, pref_pow2: 2 }), TyLayout { ty: usize, details: LayoutDetails { variants: Single { index: 0 }, fields: Union(0), abi: Scalar(Scalar { value: Int(I32, false), valid_range: 0..=4294967295 }), align: Align { abi_pow2: 2, pref_pow2: 2 }, size: Size { raw: 4 } } }, src/medium.rs:431:69: 431:91)

Do you have any pointers on how I can efficiently find out where in my code I have to look to isolate the offending code? I have no idea how to figure out a test case, as the crate contains a lot of code.

[cramertj]

Can you confirm that an older compiler version still works and successfully compiles your code?

[estebank]

I believe it was caused by this change, as to_immediate panics in this way:

ad2de8b#diff-9e103702275cbef342c2decd3395bf3bR578

CC @RalfJung

[jerous86]

rustup install 1.28.0 && rustup default 1.28.0 && cargo build --release
compiles without errors

[RalfJung]

I am afraid it is very hard to do anything without a way to reproduce the problem. It would be great if you could attempt to remove module by module from your crate to isolate the issue.

@jerous86 the backtrace is unfortunately not very useful because it lacks line numbers. Could you compile rustc on your machine, with debuginfo-lines = true in config.toml, and use that to compile your project and get a better backtrace?

[RalfJung]

@estebank Given #54541 (comment) I think the issue is older than that. It seems it already triggered

rust/src/librustc_mir/transform/const_prop.rs

Line 619 in aa3ca19

_ => bug!("const index not primitive: {:?}", index),

That is really old so I do not know how this even worked with 1.28.

[jerous86]

I tried building the rust compiler, but kept on running into issues, and unfortunately don't have the time to figure it all out, just to enable the debuginfo-lines, so I am going to wait until it is enabled by default (I hope #54459 is going to get merged soon?)

I will try to figure out a minimal scenario, but it might take a while ...

[jerous86]

I have found that the following scenario reproduces the ICE:

fn main() {
    enum Enum { One=1 } 
    let xs=[0;1 as usize];
    println!("{}", xs[Enum::One as usize]);
}

When replacing "One=1" with "One=0" it compiles without error.

[estebank]

I believe it's the same underlying issue as #55772.

[RalfJung]

That seems likely. const_prop strikes again :/