ICE: 'rustc' failed at 'index out of bounds: the len is 12 but the index is 12 - triggered by number of LoC

[japaric]

Believed current test case

(pnkfelix says: "if you are looking at this bug, please try to keep this test up-to-date ... potentially by checking the newest linked dupes in the comment feed below.")

// Very

// sensitive
pub struct BytePos(pub u32);

// to particular

// line numberings / offsets

fn main() {
    let x = BytePos(1);

    assert!(x, x);
}

Original Bug Filed

Script to reproduce:

fn main() {
    // if any comment line is removed, the ICE disappears
    // adding more lines keep the ICE alive
    //
    //
    //
    //
    //
    //
    //
    //
    //
    assert!(vec!(1.0), vec!(1.0))
}

Backtrace:

$ RUST_BACKTRACE=1 rustc ice.rs
<std macros>:8:12: 13:23 error: cannot apply unary operator `!` to type `std::vec::Vec<<generic float #0>>`
<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://static.rust-lang.org/doc/master/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', /var/tmp/paludis/build/dev-lang-rust-scm/work/rust-scm/src/libsyntax/lib.rs:1
stack backtrace:
   1:     0x7f0c3dda8180 - rt::backtrace::imp::write::h706b65acfe967902xTF::v0.11.pre
   2:     0x7f0c3dd11730 - rt::unwind::begin_unwind_inner::hcc57db58853efcfdAtF::v0.11.pre
   3:     0x7f0c3dda7e10 - <unknown>
   4:     0x7f0c3dda7d30 - rust_fail_bounds_check
   5:     0x7f0c3ddb9a90 - failure::fail_bounds_check::h8ed58f060b870dd6EwF::v0.11.pre
   6:     0x7f0c3d1d80f0 - codemap::FileMap::get_line::hbf104ad3bfda6f77Drd::v0.11.pre
   7:     0x7f0c3d1d4e90 - <unknown>
   8:     0x7f0c3d1ccd40 - diagnostic::EmitterWriter.Emitter::emit::h7c42f3840a82760aQcc::v0.11.pre
   9:     0x7f0c3d1c9f90 - diagnostic::Handler::emit::h971cc5635478154dV0b::v0.11.pre
  10:     0x7f0c3d1c8ec0 - diagnostic::SpanHandler::span_err::h3735f152282993cc3Sb::v0.11.pre
  11:     0x7f0c3eadda90 - middle::typeck::infer::InferCtxt<'a>::type_error_message_str_with_expected::he1b302cd7901cc2apJq::v0.11.pre
  12:     0x7f0c3eb7f0e0 - middle::typeck::infer::InferCtxt<'a>::type_error_message::h6e536a01d806a7af7Qq::v0.11.pre
  13:     0x7f0c3eb8d9f0 - <unknown>
  14:     0x7f0c3eb8b250 - <unknown>
  15:     0x7f0c3eb8d650 - <unknown>
  16:     0x7f0c3eb7fb20 - <unknown>
  17:     0x7f0c3eb7fb20 - <unknown>
  18:     0x7f0c3eb5fd00 - middle::typeck::check::check_block_with_expected::hec61a0d86b711c5ck7c::v0.11.pre
  19:     0x7f0c3eb5af90 - <unknown>
  20:     0x7f0c3eb5ad30 - <unknown>
  21:     0x7f0c3eb53790 - middle::typeck::check::check_item::he7c19452bac809220R8::v0.11.pre
  22:     0x7f0c3eb5ab30 - middle::typeck::check::check_item_types::hca38e25e2d3c1969ek8::v0.11.pre
  23:     0x7f0c3ec9d280 - <unknown>
  24:     0x7f0c3ec9c090 - middle::typeck::check_crate::h540b9b663571145fQgw::v0.11.pre
  25:     0x7f0c3f0e8e90 - driver::driver::phase_3_run_analysis_passes::h129732fc31300f8bbei::v0.11.pre
  26:     0x7f0c3f0eef10 - driver::driver::compile_input::h36b4d97be6c65511gEi::v0.11.pre
  27:     0x7f0c3f1143c0 - run_compiler::hd111892d49d8dfe1saq::v0.11.pre
  28:     0x7f0c3f12ffb0 - <unknown>
  29:     0x7f0c3f12e860 - <unknown>
  30:     0x7f0c3f129020 - <unknown>
  31:     0x7f0c3e2ce670 - <unknown>
  32:     0x7f0c3dd9f430 - <unknown>
  33:     0x7f0c3ddc04a0 - rust_try
  34:     0x7f0c3dd9f270 - rt::task::Task::run::hd2e6ec18f16de5eeiiD::v0.11.pre
  35:     0x7f0c3e2ce440 - <unknown>
  36:     0x7f0c3dda6c60 - <unknown>
  37:     0x7f0c3ba9c000 - start_thread
  38:     0x7f0c3d9e43d9 - clone
  39:                0x0 - <unknown>

Version:

$ rustc --version
rustc 0.11-pre (1001635 2014-05-10 09:56:34 -0700)
host: x86_64-unknown-linux-gnu

[erickt]

I've auto-reduced this down to:

fn main() {
  //
  //
  //
  //
  //
  //
  //
  //
  //
  //
  //
  assert !(vec !(), vec !())
}

thanks creduce and @regehr!

[klutzy]

macros.rs:

#![macro_escape]
macro_rules! assert_ (
    ($cond:expr, $($arg:expr)+) => (
        if !$cond { fail!($($arg),+) }
    )
) // 6 lines

main.rs:

#![feature(macro_rules)]




mod macros;
fn main(){assert_!(1,1)} // 7th line

task 'rustc' failed at 'index out of bounds: the len is 6 but the index is 6', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/lib.rs:1

Seems like something is wrong in filemap.

[tshepang]

I can't repdrouce this no more on master branch: http://is.gd/9Is9bB.

[klutzy]

It's still present with assert!(1u, 1u);.

[klutzy]

The core issue is: the assertion is expanded into if !1u { ... } which causes type error as expected. However, ! token is from macro (if !$cond), while 1u is from assert!(1u, 1u). They are even in different files! Here span computation goes bad, and printer tries to print wrong code area.