ICE in ... bound check?

[frankmcsherry]

I'm sorry I don't have a minimal repro for this. It's a non-small project and no hints from rustc about where it is when it explodes. This is after fixing a lot of other bugs (mine), so it's not clearly swapping in/out some lines that makes it explode. I'm not exactly clear on the version; just refreshed rust a few mins ago (Jan 12), but the version info suggests Jan 8, 2015. =/

Echidnatron% rustc --version
rustc 1.0.0-nightly (44a287e6e 2015-01-08 17:03:40 -0800)
Echidnatron% cargo build

   Compiling timely v0.0.4 (file:///Users/mcsherry/Projects/timely-dataflow)
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 31', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc/lib.rs:1

stack backtrace:
   1:        0x1067bc4b5 - sys::backtrace::write::h64ca2fb259c4ae97lCt
   2:        0x1067de94f - failure::on_fail::h64ff5ae6887860cc0Hz
   3:        0x10674a5ca - rt::unwind::begin_unwind_inner::h1d4bc098fd350446Qpz
   4:        0x10674a7c4 - rt::unwind::begin_unwind_fmt::h2787666abdf9afbbnoz
   5:        0x1067de3be - rust_begin_unwind
   6:        0x106829627 - panicking::panic_fmt::h147727a519895962pfl
   7:        0x106832db1 - panicking::panic_bounds_check::h7f4dce76ef1e56a3qel
   8:        0x103b73deb - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::ha85d79855d8194e3tiy
   9:        0x103b75be4 - middle::ty_fold::super_fold_binder::h6928004149813632843
  10:        0x103b759d7 - vec::Vec<T>.FromIterator<T>::from_iter::h10666903031803559849
  11:        0x103b73da1 - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::ha85d79855d8194e3tiy
  12:        0x103b737fc - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::ha85d79855d8194e3tiy
  13:        0x103b755f0 - middle::ty_fold::TypeFolder::fold_substs::h13316661140596178829
  14:        0x103b73af7 - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::ha85d79855d8194e3tiy
  15:        0x103b755f0 - middle::ty_fold::TypeFolder::fold_substs::h13316661140596178829
  16:        0x103b73af7 - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::ha85d79855d8194e3tiy
  17:        0x103b755f0 - middle::ty_fold::TypeFolder::fold_substs::h13316661140596178829
  18:        0x103b73af7 - middle::infer::freshen::TypeFreshener<'a, 'tcx>.TypeFolder<'tcx>::fold_ty::ha85d79855d8194e3tiy
  19:        0x103b755f0 - middle::ty_fold::TypeFolder::fold_substs::h13316661140596178829
  20:        0x103c00549 - middle::traits::select::SelectionContext<'cx, 'tcx>::push_stack::h086523854b612de0x0T
  21:        0x103be6835 - middle::traits::select::SelectionContext<'cx, 'tcx>::select::h40303230723bb5b2GmR
  22:        0x103be44a1 - middle::traits::fulfill::FulfillmentContext<'tcx>::select::hd311ca92298c935c5uP
  23:        0x103be395f - middle::traits::fulfill::FulfillmentContext<'tcx>::select_where_possible::h0ddf391ab631b9dcbuP
  24:        0x103acba32 - middle::traits::fulfill::FulfillmentContext<'tcx>::select_all_or_error::h92b4107ce8dc017fbsP
  25:        0x103c1f08a - middle::traits::evaluate_builtin_bound::h74dc7e99b16f4d13n6U
  26:        0x103c1fa7f - middle::traits::type_known_to_meet_builtin_bound::h56a9457efea34e16KbV
  27:        0x103c4303a - middle::ty::type_impls_bound::h82008369896b1e41he6
  28:        0x103aadd4a - ast_util::walk_pat::walk_pat_::h12435846749475835187
  29:        0x103a8013b - middle::check_match::check_legality_of_move_bindings::h74497930dc861cecYSf
  30:        0x103a7d746 - middle::check_match::check_local::h1b937e5e865b6384dLf
  31:        0x103a7ff24 - visit::walk_block::h12902511854168785145
  32:        0x103a7dacc - middle::check_match::check_fn::h20cbef0cce6eb997iNf
  33:        0x103a7f88e - visit::walk_method_helper::h3692137077735596901
  34:        0x103a7ef5c - visit::walk_item::h9439576440359687080
  35:        0x103a7e31f - visit::walk_mod::h6046643150159550950
  36:        0x103a7e31f - visit::walk_mod::h6046643150159550950
  37:        0x103a7e22b - middle::check_match::check_crate::h56a168d2868fec3bCze
  38:        0x102fda87e - driver::phase_3_run_analysis_passes::h4c5cf0d8fe5d55degwa
  39:        0x102fbf420 - driver::compile_input::h31580cbd7ea87613xba
  40:        0x10308afda - monitor::unboxed_closure.22557
  41:        0x103089735 - thunk::F.Invoke<A, R>::invoke::h6367419564961841226
  42:        0x103088510 - rt::unwind::try::try_fn::h7763956589852599824
  43:        0x1068452a9 - rust_try_inner
  44:        0x106845296 - rust_try
  45:        0x103088c0c - thunk::F.Invoke<A, R>::invoke::h16724184168577887652
  46:        0x1067cc154 - sys::thread::thread_start::hbd8f2f8bdd3a3baadrw
  47:     0x7fff94afa2fc - _pthread_body
  48:     0x7fff94afa279 - _pthread_body

Could not compile `timely`.

To learn more, run the command again with --verbose.
Echidnatron% 

[frankmcsherry]

This is still present in

Echidnatron% rustc --version
rustc 1.0.0-nightly (3d0d9bb6f 2015-01-12 22:56:20 +0000)

The code that causes this is checked in at https://github.com/frankmcsherry/timely-dataflow.

[frankmcsherry]

More poking around suggests that the ICE goes away when the (only) member of the following struct is commented out (and its implementations updated to be no-ops):

pub struct OutputPort<T: Timestamp, D: Data> {
    pub shared:    Rc<RefCell<Vec<Box<Observer<Time=T, Data=D>>>>>,
}

The only implementation OutputPort has is for Observer (with associated types Time = T and Data = D) and just maps each method across the members. It's all in src/communication/observer.rs, if that is helpful.

No clue if a) I'm doing it wrong, or b) not expected to work anyhow, or c) it should work; is bug.

[frankmcsherry]

More information. I'm able to get rustc to not ICE without removing any code, by adding an explicit type annotation elsewhere. Just before the OutputPort struct above is constructed, I have (approximately; some code elided):

let targets = Rc::new(RefCell::new(Vec::new()));
self.add_observer(OutputPort { shared: targets.clone() });

This ICEs, but if I add in a type annotation for targets:

let targets: Rc<RefCell<Vec<Box<Observer<Time=T, Data=D>>>>> = Rc::new(RefCell::new(Vec::new()));
self.add_observer(OutputPort { shared: targets.clone() });

all is well. Not sure if this is an error without the annotation (and rustc is indirectly telling me it couldn't do type inference) or it should work and is just tickling some previously un-tickled code.

Anyhow, hope this helps!

[tamird]

@frankmcsherry in the minimum number of steps: how do I reproduce this?

[frankmcsherry]

Sorry, this was about three months ago. I just pulled the commit to see if (by chance) there was still an ICE, but it doesn't build because it was written against pre-beta Rust and the language has changed so much. Closing as "can't reproduce", I guess?