Internal Compiler Error while asserting against an enum

[fmendez]

Code to reproduce the error:

#[deriving(PartialEq,Show)]
pub enum SomeObject{
  SomeString(String),
  SomeInteger(i64),
  SomeArray(Vec<SomeObject>),
}

fn somefunction()-> Option<SomeObject>{
  if true{
    Some(SomeString("foo".to_string()))
  }else{
    None
  }
}


fn main(){
  match somefunction(){
    Some(s) => assert!(s,SomeString("foo")),
    None => println!("bad luck")
  }  
}

Result:

experiment $> RUST_BACKTRACE=1 cargo run                                                                                                                                      [ ruby-2.1.1 ]
   Compiling experiment v0.1.0 (file:/Users/fmendez/Desktop/start/quick_hacking/rust-practice/experiment)
<std macros>:8:12: 43:25 error: cannot apply unary operator `!` to type `SomeObject`
<std macros>:8         if !$cond {
<std macros>:9             fail!($($arg),+)
<std macros>:10         }
<std macros>:11     );
<std macros>:12 )
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. 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' failed at 'index out of bounds: the len is 12 but the index is 12', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libsyntax/lib.rs:1

stack backtrace:
   1:        0x10ffd4c18 - rt::backtrace::imp::write::h43147c4def9aa280Ffq
   2:        0x10ffd8405 - failure::on_fail::h9c97bab6285818b6Yvq
   3:        0x11028c1f9 - unwind::begin_unwind_inner::h81399a9c65ee74ceAXd
   4:        0x11028bd87 - unwind::begin_unwind_fmt::hd65266271db9adc53Ud
   5:        0x11028bb41 - rust_begin_unwind
   6:        0x1102d9cce - failure::begin_unwind::hd86dd9ec804771d4Gsj
   7:        0x1102e0749 - failure::fail_bounds_check::h4cb06daf33134d12Sqj
   8:        0x10f674f34 - codemap::FileMap::get_line::h0e953a490dba89faaXB
   9:        0x10f681096 - diagnostic::emit::h5dbcf8620b336a1exkD
  10:        0x10f67ce74 - diagnostic::EmitterWriter.Emitter::emit::hc8ebf8e51adc4fa1wgD
  11:        0x10f67ad3e - diagnostic::Handler::emit::h1876872ac38fe4dejYC
  12:        0x10f672dd5 - diagnostic::SpanHandler::span_err::hdbe260bbdeb451deANC
  13:        0x10d0e29c1 - middle::typeck::infer::InferCtxt<'a>::type_error_message_str_with_expected::h8924f9b9e9f50a08OTC
  14:        0x10d189dd0 - middle::typeck::infer::InferCtxt<'a>::type_error_message::hb1ada444d64c239aw1C
  15:        0x10d19ad10 - middle::typeck::check::check_expr_with_unifier::check_user_unop::closure.$x22closure$x22$LP$110674$RP$
  16:        0x10d198686 - middle::typeck::check::check_expr_with_unifier::lookup_op_method::h4e4be668cec4d869Ojl
  17:        0x10d19aaeb - middle::typeck::check::check_expr_with_unifier::check_user_unop::hfb0dd1641bea4d1bFyl
  18:        0x10d1928ad - middle::typeck::check::check_expr_with_unifier::h702071da724e08c835k
  19:        0x10d18f9f7 - middle::typeck::check::check_expr_with_unifier::h702071da724e08c835k
  20:        0x10d0d8294 - middle::typeck::check::_match::check_match::h8946955578835696wz9
  21:        0x10d18fbbc - middle::typeck::check::check_expr_with_unifier::h702071da724e08c835k
  22:        0x10d1662f6 - middle::typeck::check::check_block_with_expected::h2eb3aca62441a33688m
  23:        0x10d161a7d - middle::typeck::check::check_fn::h0c5443287d13fc5bNmi
  24:        0x10d161412 - middle::typeck::check::check_bare_fn::hd69ba226c9d1758doci
  25:        0x10d15a562 - middle::typeck::check::check_item::h5557b190840cc4ff4Ki
  26:        0x10d16118d - middle::typeck::check::check_item_types::h3a5ec6d1fe53f89eGbi
  27:        0x10d2cd74e - middle::typeck::check_crate::h815ace21bf7513b5Y3I
  28:        0x10d6441d9 - driver::driver::phase_3_run_analysis_passes::h3b364399f6023cbd37t
  29:        0x10d63f601 - driver::driver::compile_input::h7eed16699446a4bc4Tt
  30:        0x10d6f41b8 - driver::run_compiler::h07bacfcf2975c02fK1w
  31:        0x10d6f1886 - driver::main_args::closure.$x22closure$x22$LP$134904$RP$
  32:        0x10d704a0b - task::TaskBuilder<S>::try_future::closure.$x22closure$x22$LP$136053$RP$
  33:        0x10d704901 - task::TaskBuilder<S>::spawn_internal::closure.$x22closure$x22$LP$136030$RP$
  34:        0x10ff0363c - task::spawn_opts::closure.$x22closure$x22$LP$8272$RP$
  35:        0x1102f136c - rust_try
  36:        0x110288f5b - unwind::try::hbd282dff76a810e4ZLd
  37:        0x110288cc3 - task::Task::run::hb37a5b83f7232860RXc
  38:        0x10ff034d1 - task::spawn_opts::closure.$x22closure$x22$LP$8217$RP$
  39:        0x11028af56 - thread::thread_start::h0e9d7a12ab365fe6pkd
  40:     0x7fff901b9899 - _pthread_body
  41:     0x7fff901b972a - _pthread_struct_init

rustc -v :

rustc 0.12.0-pre-nightly (441866417764cb0ad32bce50ebda83deec525997 2014-07-18 11:51:20 +0000)

OS: OSX

[aochagavia]

This issue is unrelated to enums. The real problem here is using assert!(a, b), which causes an ICE instead of giving a compile error (see issue #15901). Using assert_eq!(a, b) or assert!(a == b) is the right thing to do and won't cause problems.

@alexcrichton I think this should be closed.

[alexcrichton]

Yes this looks to be a dupe of #15901.