ICE "broken MIR ((*var0)): "deref of non-pointer [...]" "

[PieterPenninckx]

The following code makes rustc panic:

trait ITrait<'a> {type Item;}

struct S {}

impl<'a> ITrait<'a> for S { type Item = &'a mut usize; }

fn m<T, I, F>(mut f: F)
    where I: for<'a> ITrait<'a>,
          F: for<'a> FnMut(<I as ITrait<'a>>::Item)
{ unimplemented!()}


fn main() {
    m::<usize,S,_>(|x| { *x += 1; });
}

Before panicking, rustc gives a warning:

bug_report.rs:14:26: 14:33 warning: broken MIR ((*var0)): "deref of non-pointer <S as ITrait<\'a>>::Item"
bug_report.rs:14     m::<usize,S,_>(|x| { *x += 1; });
                                          ^~~~~~~
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 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:325

Meta

rustc --version --verbose:

rustc 1.11.0 (9b21dcd6a 2016-08-15)
binary: rustc
commit-hash: 9b21dcd6a89f38e8ceccb2ede8c9027cb409f6e3
commit-date: 2016-08-15
host: x86_64-unknown-linux-gnu
release: 1.11.0

Backtrace:

stack backtrace:
   1:     0x7f33221c6e2f - std::sys::backtrace::tracing::imp::write::h46e546df6e4e4fe6
   2:     0x7f33221d513b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h077deeda8b799591
   3:     0x7f33221d4cd8 - std::panicking::default_hook::heb8b6fd640571a4f
   4:     0x7f332219aade - std::panicking::rust_panic_with_hook::hd7b83626099d3416
   5:     0x7f33221d5381 - std::panicking::begin_panic::h941ea76fc945d925
   6:     0x7f332219c82a - std::panicking::begin_panic_fmt::h30280d4dd3f149f5
   7:     0x7f33221d531e - rust_begin_unwind
   8:     0x7f332221e38f - core::panicking::panic_fmt::h2d3cc8234dde51b4
   9:     0x7f332221ee88 - core::panicking::panic::heeca72c448510af4
  10:     0x7f331e9a19ab - rustc::mir::tcx::LvalueTy::projection_ty::h426e2752b2ef981d
  11:     0x7f331e9a1ca4 - rustc::mir::tcx::_<impl rustc..mir..repr..Mir<'tcx>>::lvalue_ty::hb2b5f7921616ff34
  12:     0x7f331e9a228b - rustc::mir::tcx::_<impl rustc..mir..repr..Mir<'tcx>>::rvalue_ty::h154147076bc41eb9
  13:     0x7f331ff30010 - _<rustc_mir..transform..type_check..TypeVerifier<'a, 'b, 'gcx, 'tcx> as rustc..mir..visit..Visitor<'tcx>>::visit_rvalue::h3992969329e7d331
  14:     0x7f331ff30269 - _<rustc_mir..transform..type_check..TypeVerifier<'a, 'b, 'gcx, 'tcx> as rustc..mir..visit..Visitor<'tcx>>::visit_mir::h057ca1a10423df31
  15:     0x7f331ff38523 - _<rustc_mir..transform..type_check..TypeckMir as rustc..mir..transform..MirPass<'tcx>>::run_pass::h31d4990af26b9163
  16:     0x7f3322719d71 - _<T as rustc..mir..transform..MirMapPass<'tcx>>::run_pass::hdedd91383575ce3e
  17:     0x7f331e9a3913 - rustc::mir::transform::Passes::run_passes::h78a0bc9140548fba
  18:     0x7f3322719060 - rustc_driver::driver::phase_3_run_analysis_passes::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hd4dc246bd7916d92
  19:     0x7f332271254d - rustc_driver::driver::phase_3_run_analysis_passes::_$u7b$$u7b$closure$u7d$$u7d$::hded790081e457a76
  20:     0x7f332270df49 - rustc::ty::context::TyCtxt::create_and_enter::h7622c0f52ea2e7fe
  21:     0x7f33226cb80f - rustc_driver::driver::compile_input::hdfe4405d66704c31
  22:     0x7f33226b7f44 - rustc_driver::run_compiler::h581448fb74257353
  23:     0x7f33226b504e - std::panicking::try::call::hf081e8ea5e252d1a
  24:     0x7f33221e363b - __rust_try
  25:     0x7f33221e35de - __rust_maybe_catch_panic
  26:     0x7f33226b5b34 - _<F as alloc..boxed..FnBox<A>>::call_box::h2d5dcb354b3ff8db
  27:     0x7f33221d3264 - std::sys::thread::Thread::new::thread_start::hf2eed4b6f7149599
  28:     0x7f331a4570a3 - start_thread
  29:     0x7f3321e1587c - clone
  30:                0x0 - <unknown>

[TimNN]

This works fine on 1.7.0 and ice's on any later stable releases as well as current beta / nightly.

[Aatch]

A regression from stable to stable! A use for the tag!

"Fortunately", this appears to be bug in the type-checking pass run on the MIR. It's probably not handling the associated type properly for this case. I'm surprised this hasn't come up sooner to be honest.