ICE: thread 'rustc' panicked at 'index out of bounds: the len is 8 but the index is 10', src/libcollections/vec.rs:1261

[pablocouto]

The following code produces an ICE with rustc 1.3.0 (playpen):

fn main() {
    let mut v = vec![];
    let r: &&mut Vec<i32> = &mut v;
}

This is the output of RUST_BACKTRACE=1 rustc panics.rs:

panics.rs:3:29: 3:35 error: mismatched types:
 expected `&&mut collections::vec::Vec<i32>`,
    found `&mut collections::vec::Vec<_>`
(expected &-ptr,
    found struct `collections::vec::Vec`) [E0308]
panics.rs:3     let r: &&mut Vec<i32> = &mut v;
                                        ^~~~~~
panics.rs:3:29: 3:35 help: run `rustc --explain E0308` to see a detailed explanation
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
thread 'rustc' panicked at 'index out of bounds: the len is 8 but the index is 10', src/libcollections/vec.rs:1261

stack backtrace:
   1:     0x7f54c99bf66e - sys::backtrace::write::ha67a6a2049d22fadIvs
   2:     0x7f54c99c7d55 - panicking::on_panic::hfa4bf0215983f759lzx
   3:     0x7f54c998894e - rt::unwind::begin_unwind_inner::ha1b5da93bdf7e8ffC0w
   4:     0x7f54c99896b6 - rt::unwind::begin_unwind_fmt::hac9e09b20e42a51cIZw
   5:     0x7f54c99c78f6 - rust_begin_unwind
   6:     0x7f54c9a0eb64 - panicking::panic_fmt::hd75b6cee85f3afe4SgC
   7:     0x7f54c9a09b27 - panicking::panic_bounds_check::h75be7bf05a80539eYfC
   8:     0x7f54c7a8d4c6 - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::hc9c9eb98be33b949RaA
   9:     0x7f54c7a8e72c - middle::ty_fold::TypeFolder::fold_substs::h2722752635261880804
  10:     0x7f54c79f65be - middle::traits::select::SelectionContext<'cx, 'tcx>::select::h1f87e60efc15a3ecM9T
  11:     0x7f54c7b07b32 - middle::traits::fulfill::process_predicate::hb3b7f7641fd49fc3S4R
  12:     0x7f54c7b062d1 - middle::traits::fulfill::FulfillmentContext<'tcx>::select::h79dd37a3da2ede60kYR
  13:     0x7f54c7b05de7 - middle::traits::fulfill::FulfillmentContext<'tcx>::select_where_possible::h655917464134b2c15WR
  14:     0x7f54c91ad9a6 - check::FnCtxt<'a, 'tcx>::select_obligations_where_possible::h95b463f889462e983Ap
  15:     0x7f54c919ffb3 - check::FnCtxt<'a, 'tcx>::select_all_obligations_and_apply_defaults::h3ad48213dc81f2c2ilp
  16:     0x7f54c919d563 - check::check_bare_fn::hea668edfab6ab1e7Hyn
  17:     0x7f54c919b755 - check::check_item_body::h65a80a5fa29972acHYn
  18:     0x7f54c919d184 - check::check_item_types::he8badf30eb589763ewn
  19:     0x7f54c925cbab - check_crate::h341139d405597625laD
  20:     0x7f54c9f27199 - driver::phase_3_run_analysis_passes::closure.16542
  21:     0x7f54c9f25ab1 - middle::ty::ctxt<'tcx>::create_and_enter::h9578579149294230291
  22:     0x7f54c9f20991 - driver::phase_3_run_analysis_passes::h8415522514568150077
  23:     0x7f54c9f04a90 - driver::compile_input::h52c7dafd49963360Tba
  24:     0x7f54c9feaa63 - run_compiler::h473c62e00f865fa9A7b
  25:     0x7f54c9fe84de - boxed::F.FnBox<A>::call_box::h10713159552398332324
  26:     0x7f54c9fe7e09 - rt::unwind::try::try_fn::h16887904248528792425
  27:     0x7f54c99c784d - __rust_try
  28:     0x7f54c99b28f7 - rt::unwind::try::inner_try::hafffff77ddacfa5fvWw
  29:     0x7f54c9fe8028 - boxed::F.FnBox<A>::call_box::h5417278073590676257
  30:     0x7f54c99c6991 - sys::thread::Thread::new::thread_start::h29dca2a2cf2294b535v
  31:     0x7f54c423e4a3 - start_thread
  32:     0x7f54c962013c - clone
  33:                0x0 - <unknown>

Meta

rustc 1.3.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.3.0

[Manishearth]

Probably missing an abort_if_errors() somewhere

[barosl]

It seems that fcx.select_all_obligations_and_apply_defaults() in check_bare_fn is causing the ICE. I was able to fix the issue by prepending abort_if_errors() before the call.

But if we do that, the maximum number of errors that can be emitted per iteration will be reduced. (If a function fails to type check, the remaining functions will not be checked at all.) Is this acceptable? Or should we find another solution? (Possibly by fixing the logic inside select_obligations_where_possible?)

[Manishearth]

Yes, that is the case. There are a couple solutions:

• See if you can abort only in the situation causing the ICE. Rather fiddly
• See if you can fix the logic so that it just propagates a TyError or whatever.

The latter would be preferred.

[arielb1]

@Manishearth

This looks like a duplicate of #24819, and @jroesch is supposed to be working on a fix.