ICE using multidispatch with unboxed closures + overloaded calls

[tomjakubowski]

use std::ops::Fn;

struct Foo;

impl Fn<(int, int), ()> for Foo {
    extern "rust-call" fn call(&self, args: (int, int)) {
        println!("{}", args);
    }
}

impl Fn<(int, int, int), ()> for Foo {
    extern "rust-call" fn call(&self, args: (int, int, int)) {
        println!("{}", args);
    }
}


fn main() {
    let foo = Foo;
    foo(1, 1);
}

FWIW it works just fine using .call((1, 1, 1)).

$ rustc --version
rustc 0.13.0-dev (18a3db6aa 2014-10-29 22:17:00 +0000)
$ RUST_BACKTRACE=1 rustc foo.rs
foo.rs:20:5: 20:14 error: the type of this value must be known in this context
foo.rs:20     foo(1, 1);
              ^~~~~~~~~
foo.rs:20:5: 20:14 error: cannot use call notation; the first type parameter for the function trait is neither a tuple nor unit [E0059]
foo.rs:20     foo(1, 1);
              ^~~~~~~~~
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 'index out of bounds: the len is 1 but the index is 1', /build/rust-git/src/rust/src/librustc/lib.rs:1

stack backtrace:
   1:     0x7fc029920da0 - rt::backtrace::imp::write::hd4d42b2a271f39bapdq
   2:     0x7fc029923ea0 - <unknown>
   3:     0x7fc02a0b3390 - unwind::begin_unwind_inner::ha369021e3864117bdSd
   4:     0x7fc02a0b2eb0 - unwind::begin_unwind_fmt::h6c1ae8b41766cb91FPd
   5:     0x7fc02a0b2e70 - rust_begin_unwind
   6:     0x7fc02a0f6dc0 - panicking::panic_fmt::hd6c7352d289b8ab4h7j
   7:     0x7fc02a0f6c60 - panicking::panic_bounds_check::h3270b40849c95c58Q5j
   8:     0x7fc02a936ad0 - <unknown>
   9:     0x7fc02a935740 - <unknown>
  10:     0x7fc02a934af0 - <unknown>
  11:     0x7fc02a938740 - <unknown>
  12:     0x7fc02a985b60 - middle::typeck::check::check_stmt::h12682851d7b97438MD0
  13:     0x7fc02a906010 - <unknown>
  14:     0x7fc02a902050 - <unknown>
  15:     0x7fc02a901d90 - <unknown>
  16:     0x7fc02a8fe070 - middle::typeck::check::check_item::h1ede54af7bac3ed7KwV
  17:     0x7fc02a901860 - middle::typeck::check::check_item_types::hcd30726f52b170bbLbV
  18:     0x7fc02a488b20 - <unknown>
  19:     0x7fc02ab95cc0 - middle::typeck::check_crate::h5d575bfd3dce804ejVn
  20:     0x7fc02abf91d0 - driver::driver::phase_3_run_analysis_passes::h58fd1c1e356530824EA
  21:     0x7fc02abf3f40 - driver::driver::compile_input::h9628c0c6c9c17838PlA
  22:     0x7fc02ac777c0 - <unknown>
  23:     0x7fc02ac776b0 - <unknown>
  24:     0x7fc02a4a1730 - <unknown>
  25:     0x7fc02a4a1520 - <unknown>
  26:     0x7fc02b4b8130 - <unknown>
  27:     0x7fc02a104a50 - <unknown>
  28:     0x7fc02a104a40 - rust_try
  29:     0x7fc02a0b0b00 - unwind::try::hca7256b355f2fe07xGd
  30:     0x7fc02a0b0990 - task::Task::run::hf4a989e4dbd46d6cnMc
  31:     0x7fc02b4b7e70 - <unknown>
  32:     0x7fc02a0b2230 - <unknown>
  33:     0x7fc0293ef250 - start_thread
  34:     0x7fc029d8d3b9 - clone
  35:                0x0 - <unknown>

[bkoropoff]

The ICE is due to a small logic bug when a type error is propagated. We probably want a separate bug to track why the overloaded call doesn't work, since it seems like it should.