ICE on const &'static closure

[llogiq]

If I try to create a const &'static Fn(u32), I trigger an ICE:

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: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: self.mode == Mode::Var', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc/middle/check_const.rs:254

error code 101

A small example code snippet is on the playpen (see http://is.gd/U0DmxV):

const x: &'static Fn() = &|| println!("ICE here"); //ICE

fn main() {}

[llogiq]

(edit: reduced the example code a bit)

[llogiq]

Rustc:

rustc 1.1.0-nightly (4356220 2015-05-04) (built 2015-05-05)
binary: rustc
commit-hash: 4356220
commit-date: 2015-05-04
build-date: 2015-05-05
host: x86_64-unknown-linux-gnu
release: 1.1.0-nightly

Backtrace:

thread 'rustc' panicked at 'assertion failed: self.mode == Mode::Var', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc/middle/check_const.rs:256

stack backtrace:
   1:     0x7f53daf5a099 - sys::backtrace::write::h5f9c68bafc81b9cffhs
   2:     0x7f53daf61fe9 - panicking::on_panic::h373abe6a65309d56eXw
   3:     0x7f53daf22202 - rt::unwind::begin_unwind_inner::h5188f63ed8e7a8f4oCw
   4:     0x7f53d8dc7bae - rt::unwind::begin_unwind::h17431745025147829990
   5:     0x7f53d8f10412 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_fn::h3de92c228569f0fdoQd
   6:     0x7f53d8f1339b - visit::walk_expr::h15305561305326812834
   7:     0x7f53d8f0c168 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_expr::hd1fdf4a4113a51f0rSd
   8:     0x7f53d8f0c168 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_expr::hd1fdf4a4113a51f0rSd
   9:     0x7f53d8ef7100 - middle::check_const::CheckCrateVisitor<'a, 'tcx>::global_expr::h7ceeeec8c2ba1122RFd
  10:     0x7f53d8f17aba - middle::check_const::check_crate::hefefaa79e1429bedoke
  11:     0x7f53db4a8af7 - driver::phase_3_run_analysis_passes::h1f752cba4a23265ftGa
  12:     0x7f53db489eec - driver::compile_input::h4db3fe53fca6bc45Qba
  13:     0x7f53db542b31 - run_compiler::haed29ba6b8e4f89065b
  14:     0x7f53db540382 - boxed::F.FnBox<A>::call_box::h454497668228412666
  15:     0x7f53db53f949 - rt::unwind::try::try_fn::h14350681364391317498
  16:     0x7f53dafd5a78 - rust_try_inner
  17:     0x7f53dafd5a65 - rust_try
  18:     0x7f53db53fbe4 - boxed::F.FnBox<A>::call_box::h1654447988124325378
  19:     0x7f53daf60d81 - sys::thread::Thread::new::thread_start::he88a7f923caab202KIv
  20:     0x7f53d4fec0a4 - start_thread
  21:     0x7f53daba5cfc - clone
  22:                0x0 - <unknown>

It appears the assert!(self.mode == Mode::Var); statement in check_const.rs, Line 254 is at fault.

By the way, the ICE is reproducible with beta (on playground), too.

[llogiq]

Same thing goes if I change the const to static (obviously, since the assertion requires Var, i.e. a let-binding)

[eddyb]

Huh, this is not the no type for node 20: local l (id=20) I was expecting to see, and which has been around since forever (closures weren't accepted in constants for a long time, so parts of the compiler were ignoring the possibility of their presence).

The assert is indeed faulty, and there are two ways to handle this: either remove the assert and wrap the method in self.with_mode(Mode::Var, |v| ...) or special-case ExprClosure in this match block.

The first way has the disadvantage of duplicating the setup done here, which on second thought, seems entirely pointless (other than for expressions in [T; N] types, which should be handled separately, anyways), so having the with_mode(Mode::Var, ... wrapping in visit_fn is probably the way to go.

[llogiq]

FWIW: The ICE does no longer occur on my system (rustc 1.2.0-nightly (78c4d53 2015-05-30))

[frewsxcv]

I'll create a regression test for this

[llogiq]

@frewsxcv Use my snippet if you like.

[frewsxcv]

@llogiq Yep, I did :) It's currently in the queue