Rust: nightly ICEs on invalid code with break outside of loop

Created on 11 Jul 2017  Â·  3Comments  Â·  Source: rust-lang/rust

$ rustc --version
rustc 1.20.0-nightly (bf0a9e0b4 2017-07-10)
$ 
$ rustc tmp.rs
error[E0268]: `break` outside of loop
 --> tmp.rs:2:3
  |
2 |   break {};
  |   ^^^^^^^^ cannot break outside of a loop

error: internal compiler error: /checkout/src/librustc_typeck/check/mod.rs:1981: no type for node 8: expr { } (id=8) in fcx 0x7f60ae1f3870

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.20.0-nightly (bf0a9e0b4 2017-07-10) running on x86_64-unknown-linux-gnu

thread 'rustc' panicked at 'Box<Any>', /checkout/src/librustc_errors/lib.rs:489:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.

$ 
$ cat tmp.rs
fn main () {
  break {};
} 
$ 
C-bug I-ICE

Most helpful comment

I'm curios… do you think _keeping_ fn main() { break rust } an ICE requires an RFC? :trollface:

All 3 comments

This is present in 1.19.0-beta.3 as well, here is the backtrace:

thread 'rustc' panicked at 'Box<Any>', /checkout/src/librustc_errors/lib.rs:480
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:365
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
   6: rustc_errors::Handler::bug
   7: rustc::session::opt_span_bug_fmt::{{closure}}
   8: rustc::session::opt_span_bug_fmt
   9: rustc::session::bug_fmt
  10: rustc_typeck::check::FnCtxt::node_ty
  11: <rustc_typeck::check::regionck::RegionCtxt<'a, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  12: <rustc_typeck::check::regionck::RegionCtxt<'a, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  13: rustc::hir::intravisit::walk_expr
  14: <rustc_typeck::check::regionck::RegionCtxt<'a, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  15: rustc_typeck::check::regionck::RegionCtxt::visit_fn_body
  16: rustc_typeck::check::typeck_tables_of::{{closure}}
  17: rustc_typeck::check::typeck_tables_of
  18: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables_of<'tcx>>::try_get
  19: rustc::ty::maps::TyCtxtAt::typeck_tables_of
  20: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::typeck_tables_of
  21: rustc_typeck::check::typeck_item_bodies
  22: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_item_bodies<'tcx>>::try_get
  23: rustc::ty::maps::TyCtxtAt::typeck_item_bodies
  24: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::typeck_item_bodies
  25: rustc_typeck::check_crate
  26: rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}
  27: rustc_driver::driver::phase_3_run_analysis_passes
  28: rustc_driver::driver::compile_input
  29: rustc_driver::run_compiler

Bisecting using bisect-rust without any #![feature] annotation turned up 852b7cb91ed44f6cc77f855bd8281da4accbd2fb (#42165), but this was only the commit this issue was introduced into stable Rust.

Bisecting after I've annotated the test case with #![feature(loop_break_value)] gave me no commit since 927c55d86b0be44337f37cf5b0a76fb8ba86e06c which introduced this, so this is probably an issue since the initial implementation of loop_break_value.

I'm curios… do you think _keeping_ fn main() { break rust } an ICE requires an RFC? :trollface:

Was this page helpful?
0 / 5 - 0 ratings