Change:
<ins> fn main() { enum Enum { One=1 } let xs=[0;1 as usize]; println!("{}", xs[Enum::One as usize]); //~ ERROR the len is 1 but the index is 1 } </ins>

Discussion:
I'm trying to compile a personal project, but the compiler crashes with the following message: 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. Notes from cargo: note: rustc 1.30.0-beta.7 ( 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 <preerror: internal compiler error: toimmediate: expected Operand::Immediate, got Indirect(MemPlace { ptr: Ptr(Pointer { allocid: AllocId(), offset: Size { raw: 0 } }), align: Align { abipow2: 2, prefpow2: 2 }, extra: None }) thread 'main' panicked at 'Box<Any', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: rustcerrors::Handler::bug 8: rustc::util::bug::optspanbugfmt::{{closure}} 9: rustc::ty::context::tls::withopt::{{closure}} 10: rustc::ty::context::tls::withcontextopt 11: rustc::ty::context::tls::withopt 12: rustc::util::bug::optspanbugfmt 13: rustc::util::bug::bugfmt 14: <rustcmir::transform::constprop::ConstPropagator<'b, 'a,

'tcxas rustc::mir::visit::Visitor<'tcx::visitterminatorkind 15: <rustcmir::transform::constprop::ConstProp as rustcmir::transform::MirPass::runpass 16: rustcmir::transform::optimizedmir::{{closure}} 17: rustcmir::transform::optimizedmir 18: rustc::ty::query::querycompute::optimizedmir 19: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::optimizedmir<'tcx::compute 20: rustc::depgraph::graph::DepGraph::withtaskimpl 21: rustc::ty::context::tls::withrelatedcontext 22: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::forcequerywithjob 23: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::trygetquery 24: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx,

'tcx::instancemir 25: rustcmir::monomorphize::collector::collectitemsrec 26: rustcmir::monomorphize::collector::collectitemsrec 27: rustcmir::monomorphize::collector::collectitemsrec 28: rustcmir::monomorphize::collector::collectitemsrec 29: rustcmir::monomorphize::collector::collectitemsrec 30: rustcmir::monomorphize::collector::collectitemsrec 31: rustcmir::monomorphize::collector::collectitemsrec 32: rustcmir::monomorphize::collector::collectitemsrec 33: rustcmir::monomorphize::collector::collectitemsrec 34: rustcmir::monomorphize::collector::collectitemsrec 35: rustcmir::monomorphize::collector::collectitemsrec 36: rustcmir::monomorphize::collector::collectitemsrec 37: rustcmir::monomorphize::collector::collectitemsrec 38: rustcmir::monomorphize::collector::collectcratemonoitems::{{closure}} 39: rustc::util::common::time 40: rustcmir::monomorphize::collector::collectcratemonoitems 41: rustc::util::common::time 42: rustccodegenllvm::base::collectandpartitionmonoitems 43: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::collectandpartitionmonoitems<'tcx::compute 44: rustc::depgraph::graph::DepGraph::withtaskimpl 45: rustc::ty::context::tls::withrelatedcontext 46: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::forcequerywithjob 47: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,

'tcx::getquery 48: rustccodegenllvm::base::codegencrate 49: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 50: rustc::util::common::time 51: rustcdriver::driver::phase4codegen 52: rustcdriver::driver::compileinput::{{closure}} 53: rustc::ty::context::tls::entercontext 54: <std::thread::local::LocalKey<T::with 55: rustc::ty::context::TyCtxt::createandenter 56: rustcdriver::driver::compileinput 57: rustcdriver::runcompilerwithpool 58: rustcdriver::driver::spawnthreadpool 59: rustcdriver::runcompiler 60: <scopedtls::ScopedKey<T::set 61: syntax::withglobals 62: rustmaybecatchpanic at 63: rustcdriver::run 64: rustcdriver::main 65: std::rt::langstart::{{closure}} 66: std::panicking::try::docall at at 67: rustmaybecatchpanic at 68: std::panic::catchunwind at at 69: std::rt::langstartinternal at 70: main 71: libcstartmain query stack during panic: [optimizedmir] processing [collectandpartitionmonoitems] collectandpartitionmonoitems end of query stack error: aborting due to previous error </pre
Does this mean that you do not see the error on stable? Are you able to provide a test case?
Sorry, I hadn't tested yet with stable. I just did, and with stable (rustc 1.29.0 ( 2018-09-11) running on armv7-unknown-linux-gnueabihf) it also crashes, but now giving a different compiler error: 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.
Can you confirm that an older compiler version still works and successfully compiles your code?

I believe it was caused by this change, as panics in this way: CC
compiles without errors
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. the backtrace is unfortunately not very useful because it lacks line numbers. Could you compile rustc on your machine, with in , and use that to compile your project and get a better backtrace?
Given I think the issue is older than that. It seems it already triggered That is really old so I do not know how this even worked with 1.28.
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 is going to get merged soon?) I will try to figure out a minimal scenario, but it might take a while ...
I have found that the following scenario reproduces the ICE: When replacing "One=1" with "One=0" it compiles without error.
I believe it's the same underlying issue as .
That seems likely. strikes again :/