ICE when simplest rust-call method is called

[nagisa]

Derivation of #16039, which was closed because it failed to compile for other reasons:

struct A;
impl A {
    extern "rust-call" fn b(i: i32) {}
}

fn main () {
    A::b(10);
}

error: internal compiler error: argument to function with "rust-call" ABI is neither a tuple nor unit
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
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:189

stack backtrace:
   1:     0x7f3d5137aa60 - sys::backtrace::write::h17046f691c944fd6wlB
   2:     0x7f3d513a3650 - failure::on_fail::hc6163ed550dbd15faOK
   3:     0x7f3d512e9e10 - rt::unwind::begin_unwind_inner::hf466231ca0fbfbbdvsK
   4:     0x7f3d4e6569c0 - rt::unwind::begin_unwind::h15994696547183619422
   5:     0x7f3d4e657180 - diagnostic::Handler::bug::h1bc3ded4b9cf6157abF
   6:     0x7f3d4f359030 - session::Session::bug::h0d2283befd4ab8993ds
   7:     0x7f3d500a4bd0 - trans::type_of::type_of_rust_fn::h653f330b805e918apWo
   8:     0x7f3d500acac0 - trans::base::decl_rust_fn::h55f15a19d1270dfe9gs
   9:     0x7f3d500bfe70 - trans::base::register_fn::h09121dffeb6c811fDXu
  10:     0x7f3d500c1e10 - trans::base::register_method::h49e3ff79a84c5d89ZBv
  11:     0x7f3d4ffd5b30 - trans::base::get_item_val::hc88b3b1356c15164vkv
  12:     0x7f3d4ffd3410 - trans::base::trans_item::ha4ea07b91896bde9tPu
  13:     0x7f3d500c20f0 - trans::base::trans_crate::hc435c9fdb6f30ff4NMv
  14:     0x7f3d519c5250 - driver::phase_4_translate_to_llvm::hb02bd998f41b29a0wPa
  15:     0x7f3d5199e170 - driver::compile_input::h91ff1ed16e22d05cEba
  16:     0x7f3d51a71ea0 - run_compiler::h9c581f85e29a6b265bc
  17:     0x7f3d51a70500 - thunk::F.Invoke<A, R>::invoke::h5155567596601403298
  18:     0x7f3d51a6f3f0 - rt::unwind::try::try_fn::h5629523784837248188
  19:     0x7f3d5140ff20 - rust_try_inner
  20:     0x7f3d5140ff10 - rust_try
  21:     0x7f3d51a6f6a0 - thunk::F.Invoke<A, R>::invoke::h7807062886684583533
  22:     0x7f3d5138f190 - sys::thread::thread_start::h57c9c75c73c301cbfVF
  23:     0x7f3d4b3312b0 - start_thread
  24:     0x7f3d50f70249 - __clone
  25:                0x0 - <unknown>

[nagisa]

Alternative backtrace:

trait B {
    extern "rust-call" fn b(i: i32) {}
}
struct A;
impl B for A {}
fn main () {
    <A as B>::b(10);
}

error: internal compiler error: argument to function with "rust-call" ABI is neither a tuple nor unit
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
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:189

stack backtrace:
   1:     0x7fa130b68a60 - sys::backtrace::write::h17046f691c944fd6wlB
   2:     0x7fa130b91650 - failure::on_fail::hc6163ed550dbd15faOK
   3:     0x7fa130ad7e10 - rt::unwind::begin_unwind_inner::hf466231ca0fbfbbdvsK
   4:     0x7fa12de449c0 - rt::unwind::begin_unwind::h15994696547183619422
   5:     0x7fa12de45180 - diagnostic::Handler::bug::h1bc3ded4b9cf6157abF
   6:     0x7fa12eb47030 - session::Session::bug::h0d2283befd4ab8993ds
   7:     0x7fa12f892bd0 - trans::type_of::type_of_rust_fn::h653f330b805e918apWo
   8:     0x7fa12f89aac0 - trans::base::decl_rust_fn::h55f15a19d1270dfe9gs
   9:     0x7fa12f7d3a20 - trans::monomorphize::monomorphic_fn::closure.41094
  10:     0x7fa12f7c67d0 - trans::monomorphize::monomorphic_fn::hf0c9202f660b2747RAd
  11:     0x7fa12f80a020 - trans::callee::trans_fn_ref_with_substs::hf1f1aa6751244623DDg
  12:     0x7fa12f808d00 - trans::meth::trans_static_method_callee::h4e4e9f0617eb5a10shz
  13:     0x7fa12f805b30 - trans::callee::trans::h2ae2f86c822ea322rgg
  14:     0x7fa12f81c590 - trans::callee::trans_call_inner::h12505348671615469836
  15:     0x7fa12f824dd0 - trans::expr::trans_rvalue_dps_unadjusted::h2a5828c13afa2678YZi
  16:     0x7fa12f7dad00 - trans::expr::trans_into::h8fd4f8a9bb5dccd8YFh
  17:     0x7fa12f7da1a0 - trans::controlflow::trans_stmt_semi::hccf4a17010754a60Zde
  18:     0x7fa12f7db310 - trans::controlflow::trans_block::hc124f866353eafbdQee
  19:     0x7fa12f8a8a20 - trans::base::trans_closure::h6c5fc36e7a33e12eofu
  20:     0x7fa12f7c6270 - trans::base::trans_fn::h76390f46f62f07cdEqu
  21:     0x7fa12f7c1410 - trans::base::trans_item::ha4ea07b91896bde9tPu
  22:     0x7fa12f8b00f0 - trans::base::trans_crate::hc435c9fdb6f30ff4NMv
  23:     0x7fa1311b3250 - driver::phase_4_translate_to_llvm::hb02bd998f41b29a0wPa
  24:     0x7fa13118c170 - driver::compile_input::h91ff1ed16e22d05cEba
  25:     0x7fa13125fea0 - run_compiler::h9c581f85e29a6b265bc
  26:     0x7fa13125e500 - thunk::F.Invoke<A, R>::invoke::h5155567596601403298
  27:     0x7fa13125d3f0 - rt::unwind::try::try_fn::h5629523784837248188
  28:     0x7fa130bfdf20 - rust_try_inner
  29:     0x7fa130bfdf10 - rust_try
  30:     0x7fa13125d6a0 - thunk::F.Invoke<A, R>::invoke::h7807062886684583533
  31:     0x7fa130b7d190 - sys::thread::thread_start::h57c9c75c73c301cbfVF
  32:     0x7fa12ab1f2b0 - start_thread
  33:     0x7fa13075e249 - __clone
  34:                0x0 - <unknown>

[tamird]

Triage: still ICEs.

#![feature(unboxed_closures)]

struct A;
impl A {
    extern "rust-call" fn b() {}
}

fn main () {
    A::b();
}

[arielb1]

Also reachable more "legitimately"

#![feature(unboxed_closures, core)]

pub struct HttpConnector<T = NoSslVerify>(Option<T>);
pub struct NoSslVerify;

impl<'a> FnOnce<&'a mut u8> for NoSslVerify {
    type Output = ();
    #[inline(always)]
    extern "rust-call" fn call_once(self, _: (&mut u8)) {}
}

[steveklabnik]

Triage: tracked by glacier

[Rufflewind]

Ran into this same bug in a way very similar to @arielb1. Of course, it's my fault: I should have used (i64,) rather than a bare i64, but I suppose less scary error message would be nice.

#![feature(fn_traits)]
#![feature(unboxed_closures)]

struct Foo;

impl FnOnce<i64> for Foo {
    type Output = ();
    extern "rust-call" fn call_once(mut self, _: i64) { }
}

fn main() { }

error: internal compiler error: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc_trans/abi.rs:371: argument to function with "rust-call" ABI is not a tuple

Couldn't get a backtrace because whenever I set RUST_BACKTRACE=1 the compiler just hangs after the ICE.

[ljedrz]

Doesn't ICE anymore with current nightly (1.28.0 2018-06-22 cbc4c83).

[memoryruins]

The ICE returned, rustc 1.30.0-nightly (551244f 2018-09-10 )

[estebank]

Still ICEs.

CC #34901.

[pnkfelix]

I think this problem can only be witnessed via use of feature(unboxed_closures) (tracking issue #29625). The use of that feature may be able to be located in a separate crate (#34901).

But still, based on that dependence on an unstable feature that is not currently on the 2019 roadmap, I am going to triage this as P-medium for now.

If however someone can demonstrate a use of this ICE-vector via stable code (something I tried to do by going through the instances of rust-call ABI in our libstd), then we should subsequently upgrade the priority here to P-high.

[Karrq]

Still ICEs, even with a simple standing function.

Doesn't error when not calling the function.
Should E0183 be emitted?

[estebank]

No, it should have a dedicated error where the ICE is being emitted pointing at the definition saying "this fn must take a single tuple as an argument" and replace the argument being evaluated with TyErr.

[Karrq]

I meant emit the error (or the ICE) when using cargo build and not just cargo run, sorry.