ICE: task 'rustc' panicked at 'called `Option::unwrap()` on a `None` value'

[drbawb]

rustc 0.13.0-nightly (eedfc0779 2014-11-25 22:36:59 +0000)
binary: rustc
commit-hash: eedfc077964b811315589d9a70293d3ff2eb0e1d
commit-date: 2014-11-25 22:36:59 +0000
host: x86_64-unknown-linux-gnu
release: 0.13.0-nightly

cargo 0.0.1-pre-nightly (1bdfb25 2014-11-20 19:29:22 +0000)
Linux DARKBLUE 3.17.2-1-ARCH #1 SMP PREEMPT Thu Oct 30 20:49:39 CET 2014 x86_64 GNU/Linux

Wish I could offer up the code; but it's a closed source project.
This code does nothing w/ lifetime parameters or stored references, though. There's just a few boxed traits w/ a +'static bound.

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
task 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/option.rs:357

stack backtrace:
   1:     0x7f0ef3bf26c0 - rt::backtrace::imp::write::haa47b8c121fd0a91H4x
   2:     0x7f0ef3bf5790 - failure::on_fail::h677b2ecbbc3adea62wy
   3:     0x7f0ef38482b0 - unwind::begin_unwind_inner::h6076ba341dd042bdYQc
   4:     0x7f0ef3847f30 - unwind::begin_unwind_fmt::h6dced2c2ae1fae959Nc
   5:     0x7f0ef3847ef0 - rust_begin_unwind
   6:     0x7f0ef388dab0 - panicking::panic_fmt::h22463fd9b1161919gSl
   7:     0x7f0ef388b7b0 - panicking::panic::hfa5ca29d7f8b5263iPl
   8:     0x7f0ef25ae0b0 - middle::borrowck::move_data::fragments::add_fragment_siblings::h8118dbea1986aaff4Rg
   9:     0x7f0ef25ab0d0 - middle::borrowck::move_data::fragments::fixup_fragment_sets::h1b34a6c0035ee1265yg  10:     0x7f0ef25b4fa0 - middle::borrowck::move_data::FlowedMoveData<'a, 'tcx>::new::he628f6d1fa80b0e3y3h
  11:     0x7f0ef25bfc90 - middle::borrowck::build_borrowck_dataflow_data::h16660f26c7d289feIoi
  12:     0x7f0ef25bccd0 - middle::borrowck::borrowck_fn::h99143b7aee997f1fGli
  13:     0x7f0ef25be390 - visit::walk_expr::h17909264982202915119
  14:     0x7f0ef25be390 - visit::walk_expr::h17909264982202915119
  15:     0x7f0ef25be8b0 - visit::walk_block::h5615061091049522259
  16:     0x7f0ef25bccd0 - middle::borrowck::borrowck_fn::h99143b7aee997f1fGli
  17:     0x7f0ef25beda0 - visit::walk_item::h7689556238676702768
  18:     0x7f0ef25bdad0 - visit::walk_mod::h6852191264437528935
  19:     0x7f0ef25bdad0 - visit::walk_mod::h6852191264437528935
  20:     0x7f0ef25bdad0 - visit::walk_mod::h6852191264437528935
  21:     0x7f0ef25bd4d0 - middle::borrowck::check_crate::h6431f8fff14c57bbcei
  22:     0x7f0ef40810e0 - util::common::time::h1653906380813325966
  23:     0x7f0ef4218b40 - driver::driver::phase_3_run_analysis_passes::h1e6ec93ec340b11aVlS
  24:     0x7f0ef420dbc0 - driver::driver::compile_input::h3650ea3ea9db5c1312R
  25:     0x7f0ef4291a60 - driver::run_compiler::h8c15fe2011461f3690T
  26:     0x7f0ef4291950 - driver::run::closure.59868
  27:     0x7f0ef4099b60 - task::TaskBuilder::try_future::closure.38986
  28:     0x7f0ef3bc33d0 - task::TaskBuilder::spawn_internal::closure.30137
  29:     0x7f0ef38460d0 - task::Task::spawn::closure.5703
  30:     0x7f0ef38a0760 - rust_try_inner  31:     0x7f0ef38a0750 - rust_try
  32:     0x7f0ef38461b0 - unwind::try::he2929ed1852ce283jFc
  33:     0x7f0ef3845f70 - task::Task::run::h9debf4f19d281b44cOb
  34:     0x7f0ef3845b60 - task::Task::spawn::closure.5679
  35:     0x7f0ef38475b0 - thread::thread_start::hbf69e7ffa558b448f6b
  36:     0x7f0eee597250 - start_thread
  37:     0x7f0ef3518589 - clone
  38:                0x0 - <unknown>

Could not compile `kyrie`. 

[drbawb]

I've actually narrowed this down to a single match expression; I'm trying to make sense of it, or at least make a reproducible test-case.

I don't see anything particularly interesting about the match:

match msg {
    Resource{ method: verb, path: uri, payload: pl, .. } => {
        let request = Request { uid: uid, method: verb, path: uri, payload: pl };
        let result  = self.stack.process(request);
        debug!("status {}", result)
    },

    PasswordAuth{ password: pw, .. } => {
        spawn(handlers::connections::password_auth(self.context.clone(),
                                                   uid, pw, self.config.services_password));
    },

    _ => { info!("unhandled message type!"); }, 
}

It is matching a struct-like enum (defined in an external crate.)
If I take out both match-arms and leave the wildcard: the code compiles just fine. Otherwise I get the ICE w/ a similar backtrace to the one posted above.

Here is an abbreviated definition of Message (the type being matched on):

#[deriving(Clone,Decodable,Encodable,Eq,Hash,PartialEq)]
pub enum Method {
        Get,
        Put,
        Destroy,
        Publish,
        Subscribe,
}

#[deriving(Clone, Encodable, Decodable)] 
pub enum Message {
    PasswordAuth { password: String },
    Resource { method: Method, path: String, payload: Option<String> },
}

[samnardoni]

Is this an issue with namespaced enums? Perhaps it should be match msg { Message::Resource { ...?

[drbawb]

Tried using the namespaced variants, as well as removing the , ..
I don't see any noticeable change in the backtrace.

I'm wondering if it's related to the struct-like enums? This is the only code I have that uses them.

The other thing is that I'm moving values out of the enum: I'm wondering if it's interacting poorly with some of the recent changes to "structural fragments" (commit 0e06f71).

[drbawb]

If I match on &msg instead of msg and then bind the patterns by-ref and #clone() them where I was previously moving them: the code compiles as usual.

So it seems to be related to moving the values out of the struct-enum.

[drbawb]

I do have a minimally reproducible test case; but so far as I can tell you need to define it in two completely separate crates.

enumice/src/lib.rs:

pub enum Foo {
    Bar { name: String },
}

enumbin/src/main.rs:

extern crate enumice;        
use enumice::Foo;            

fn main() {
    let foo = Foo::Bar { name: format!("test") };
    match foo { 
        Foo::Bar { name } => {},        
    };
} 

When I defined enum Foo { ... } inside the same crate it did not produce the ICE.
Also interestingly enough: I had to add a variant with a String before I got the ICE.
Initially I just had a variant with an i32 and it worked fine.

[ferreum]

This also happens for me with Vec instead of String. Using ref to prevent moving the value compiles fine:
Foo::Bar { ref name } => {},

[ogham]

I'm getting this ICE as well, when I try to move values out of struct-like enums. It happens on these lines: https://github.com/ogham/arity/blob/94f7db622adb8cd51d56761f30af35d77e3c5d5b/src/ast.rs#L183

The stacktrace is somewhat different, though:

stack backtrace:

1:        0x108744bf2 - rt::backtrace::imp::write::h391b8d7e50d47c199gy

2:        0x108747d10 - failure::on_fail::h4b208e46777c3262GEy

3:        0x10899a395 - unwind::begin_unwind_inner::he78fb85bab232941fJc

4:        0x108999fa6 - unwind::begin_unwind_fmt::haa2a8c3c78f20262qGc

5:        0x108999d32 - rust_begin_unwind

6:        0x1089e4cac - panicking::panic_fmt::ha89d80dab489d365VXl

7:        0x1089df732 - panicking::panic::hdc23f6ff1a41fa31XUl

8:        0x10577f703 - middle::borrowck::move_data::fragments::add_fragment_siblings_for_extension::closure.91613

9:        0x10577e5b4 - middle::borrowck::move_data::fragments::add_fragment_siblings::h457522ea517a9b413Rg

10:        0x10577bb11 - middle::borrowck::move_data::fragments::fixup_fragment_sets::h37b889f20647c9474yg

11:        0x1057855bd - middle::borrowck::move_data::FlowedMoveData<'a, 'tcx>::new::h7d515ea0e8cc9766x3h

12:        0x105791d76 - middle::borrowck::build_borrowck_dataflow_data::h4580914dc7f1219fHoi

13:        0x10578c870 - middle::borrowck::borrowck_fn::hc6a87f7f03f5c907Fli

14:        0x10578ec23 - visit::walk_item::h13605873315878884879

15:        0x10578d4e8 - visit::walk_mod::h14427983187000498433

16:        0x10578d4e8 - visit::walk_mod::h14427983187000498433

17:        0x10578cf72 - middle::borrowck::check_crate::h3c09169822075773bei

18:        0x1051d7eff - util::common::time::h17551334739901154900

19:        0x10536c424 - driver::driver::phase_3_run_analysis_passes::hdc7a5f34c31132abVlS

20:        0x1053600ec - driver::driver::compile_input::h0131bbb57744e4eb12R

21:        0x1053dd9b5 - driver::run_compiler::hc0b7f5c8dfa75d9190T

22:        0x1053dc04e - driver::run::closure.59940

23:        0x1051eface - task::TaskBuilder::try_future::closure.39054

24:        0x108716f33 - task::TaskBuilder::spawn_internal::closure.30356

25:        0x108997f3d - task::Task::spawn::closure.5573

26:        0x1089fc76c - rust_try_inner

27:        0x1089fc756 - rust_try

28:        0x108998017 - unwind::try::h3cc54dd2c93266c5Axc

29:        0x108997dec - task::Task::run::h53730485ea854581qMb

30:        0x108997aef - task::Task::spawn::closure.5549

31:        0x1089993f7 - thread::thread_start::h0f686b08caff7754t4b

32:     0x7fff93cc52fc - _pthread_body

33:     0x7fff93cc5279 - _pthread_body

$ rustc --version

rustc 0.13.0-nightly (fac5a0767 2014-11-26 22:37:06 +0000)

[drbawb]

barosl's PR compiles my code w/ no issues 👍