ICE: borrowing same Vec when filtering that Vec results in panic

[davidrusu]

Hard to tell for me exactly what is going wrong here, but I've managed to reduce the failing code to this snippet.

I tried this code:

fn main() {
    let vec: Vec<String> = Vec::new();
    let _: Vec<(&String,)> = vec.iter()
        .map(|s| (s,))
        .filter(|(&s,)| !(vec.len() > s.len()))
        .collect();
}

I expected to see this happen:
fail to compile with error message explaining problem

Instead, this happened:
panic on compile

Meta

rustc 1.27.0 (3eda71b00 2018-06-19)
binary: rustc
commit-hash: 3eda71b00ad48d7bf4eef4c443e7f611fd061418
commit-date: 2018-06-19
host: x86_64-apple-darwin
release: 1.27.0
LLVM version: 6.0

Backtrace:

$ RUST_BACKTRACE=1 cargo build -j1
   Compiling rustc-bug v0.1.0 (file:///Users/davidrusu/Desktop/MTWABP/rustc-bug)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: (MoveData { move_paths: [MovePath { place: _0 }, MovePath { place: _1 }, MovePath { place: _2 }, MovePath { place: _3 }, MovePath { place: _4 }, MovePath { place: _5 }, MovePath { place: _6 }, MovePath { place: _7 }, MovePath { place: _8 }], moves: [mp6@bb0[6], mp6@bb2[0], mp8@bb2[4], mp3@bb3[0], mp8@bb4[0], mp5@bb4[1], mp7@bb4[1], mp7@bb4[2], mp5@bb4[3], mp4@bb4[4], mp4@bb4[5], mp3@bb4[6], mp3@bb5[0], mp0@bb5[1]], loc_map: LocationMap { map: [[[], [], [], [], [], [], [mo0]], [[]], [[mo1], [], [], [], [mo2]], [[mo3]], [[mo4], [mo5, mo6], [mo7], [mo8], [mo9], [mo10], [mo11]], [[mo12], [mo13]]] }, path_map: [[mo13], [], [], [mo3, mo11, mo12], [mo9, mo10], [mo5, mo8], [mo0, mo1], [mo6, mo7], [mo2, mo4]], rev_lookup: MovePathLookup { locals: [mp0, mp1, mp2, mp3, mp4, mp5, mp6, mp7, mp8], projections: {} }, inits: [mp1@src/main.rs:5:17: 5:47 (Deep), mp2@src/main.rs:5:18: 5:23 (Deep), mp3@src/main.rs:5:20: 5:21 (Deep), mp6@src/main.rs:5:27: 5:30 (Deep), mp5@src/main.rs:5:27: 5:36 (NonPanicPathOnly), mp8@src/main.rs:5:39: 5:40 (Deep), mp7@src/main.rs:5:39: 5:46 (NonPanicPathOnly), mp4@src/main.rs:5:26: 5:47 (Deep), mp0@src/main.rs:5:25: 5:47 (Deep)], init_loc_map: LocationMap { map: [[[], [in2], [], [], [], [in3], [in4]], [[]], [[], [], [], [in5], [in6]], [[]], [[], [in7], [], [], [in8], [], []], [[], []]] }, init_path_map: [[in8], [in0], [in1], [in2], [in7], [in4], [in3], [in6], [in5]] }, [IllegalMove { cannot_move_out_of: IllegalMoveOrigin { span: src/main.rs:5:20: 5:21, kind: BorrowedContent } }])', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
  10: <rustc_mir::transform::elaborate_drops::ElaborateDrops as rustc_mir::transform::MirPass>::run_pass
  11: rustc_mir::transform::optimized_mir::{{closure}}
  12: rustc_mir::transform::optimized_mir
  13: rustc::ty::maps::<impl rustc::ty::maps::config::QueryConfig<'tcx> for rustc::ty::maps::queries::optimized_mir<'tcx>>::compute
  14: rustc::ty::context::tls::with_context
  15: rustc::dep_graph::graph::DepGraph::with_task_impl
  16: rustc::ty::context::tls::with_related_context
  17: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  18: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  19: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::instance_mir
  20: rustc_mir::monomorphize::collector::collect_items_rec
  21: rustc_mir::monomorphize::collector::collect_items_rec
  22: rustc_mir::monomorphize::collector::collect_items_rec
  23: rustc_mir::monomorphize::collector::collect_items_rec
  24: rustc_mir::monomorphize::collector::collect_items_rec
  25: rustc_mir::monomorphize::collector::collect_items_rec
  26: rustc_mir::monomorphize::collector::collect_crate_mono_items
  27: rustc::util::common::time
  28: rustc_trans::base::collect_and_partition_translation_items
  29: rustc::ty::context::tls::with_context
  30: rustc::dep_graph::graph::DepGraph::with_task_impl
  31: rustc::ty::context::tls::with_related_context
  32: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  33: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  34: rustc_trans::base::trans_crate
  35: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
  36: rustc::util::common::time
  37: rustc_driver::driver::phase_4_translate_to_llvm
  38: rustc_driver::driver::compile_input::{{closure}}
  39: rustc::ty::context::tls::enter_context
  40: <std::thread::local::LocalKey<T>>::with
  41: rustc::ty::context::TyCtxt::create_and_enter
  42: rustc_driver::driver::compile_input
  43: rustc_driver::run_compiler_impl
  44: <scoped_tls::ScopedKey<T>>::set
  45: syntax::with_globals
  46: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  47: __rust_maybe_catch_panic
  48: rustc_driver::run
  49: rustc_driver::main
  50: std::rt::lang_start::{{closure}}
  51: std::panicking::try::do_call
  52: __rust_maybe_catch_panic
  53: std::rt::lang_start_internal
  54: main
query stack during panic:
#0 [optimized_mir] processing `main::{{closure}}`
#1 [collect_and_partition_translation_items] collect_and_partition_translation_items
end of query stack

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

note: rustc 1.27.0 (3eda71b00 2018-06-19) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `rustc-bug`.

[davidrusu]

Seems like this may be same or similar issue to #51301 but I could not make that judgement!

[estebank]

Non-repro in nightly, but present in beta and stable.

[davidrusu]

This bug seems to have been fixed in stable (1.27.1) @estebank can we close this? what's the next step?

[estebank]

Closing as I think there's already a test for it.