Compiler panics when passing a tuple struct constructor as a function with the wrong number of arguments

[grenewode]

When a tuple struct's constructor is passed to a function as a callback, the compiler panics if the constructor the wrong number of arguments.

I tried this code:

fn call<F, R>(_: F)
where
    F: FnOnce() -> R,
{
}

struct Foo(u8);

fn main() {
    // Problem is here
    call(Foo);
}

On 1.24.1, this results in the following error as expected:

error[E0593]: function is expected to take 0 arguments, but it takes 1 argument
  --> main.rs:10:5
   |
7  | struct Foo(u8);
   | --------------- takes 1 argument
...
10 |     call(Foo);
   |     ^^^^ expected function that takes 0 arguments
   |
   = note: required by `call`

error: aborting due to previous error

However, on 1.25.0, the compiler panics instead:

thread 'rustc' panicked at 'non-FnLike node found: NodeStructCtor(Tuple([StructField { span: main.rs:7:12: 7:15, name: 0, vis: Inherited, id: NodeId(17), ty: type(u8), attrs: [] }], NodeId(19)))', librustc/traits/error_reporting.rs:873:18

This may be a duplicate of #47706, although this is occuring on a newer version of the compiler.

Meta

This happens on stable and nightly
rustc --version --verbose:

rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-unknown-linux-gnu
release: 1.25.0
LLVM version: 6.0

rustup run nightly rustc --version --verbose:

rustc 1.26.0-nightly (517f24025 2018-03-31)
binary: rustc
commit-hash: 517f24025a04e09936a6d07dc5298ca2b9371329
commit-date: 2018-03-31
host: x86_64-unknown-linux-gnu
release: 1.26.0-nightly
LLVM version: 6.0

Backtrace:

thread 'rustc' panicked at 'non-FnLike node found: NodeStructCtor(Tuple([StructField { span: main.rs:7:12: 7:15, name: 0, vis: Inherited, id: NodeId(17), ty: type(u8), attrs: [] }], NodeId(19)))', librustc/traits/error_reporting.rs:873:18
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
   7: rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'gcx, 'tcx>>::report_selection_error
   8: rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'gcx, 'tcx>>::report_fulfillment_errors
   9: rustc_typeck::check::FnCtxt::select_obligations_where_possible
  10: rustc_typeck::check::FnCtxt::check_argument_types
  11: rustc_typeck::check::callee::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::confirm_builtin_call
  12: rustc_typeck::check::FnCtxt::check_expr_kind
  13: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  14: rustc_typeck::check::FnCtxt::check_block_with_expected::{{closure}}
  15: rustc_typeck::check::FnCtxt::check_block_with_expected
  16: rustc_typeck::check::FnCtxt::check_expr_kind
  17: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  18: rustc_typeck::check::FnCtxt::check_return_expr
  19: rustc_typeck::check::check_fn
  20: rustc_typeck::check::typeck_tables_of::{{closure}}
  21: rustc_typeck::check::typeck_tables_of
  22: rustc::dep_graph::graph::DepGraph::with_task_impl
  23: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables_of<'tcx>>::force
  24: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables_of<'tcx>>::try_get
  25: rustc::ty::maps::TyCtxtAt::typeck_tables_of
  26: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables_of<'tcx>>::ensure
  27: rustc_typeck::check::typeck_item_bodies
  28: rustc::dep_graph::graph::DepGraph::with_task_impl
  29: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_item_bodies<'tcx>>::force
  30: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_item_bodies<'tcx>>::try_get
  31: rustc::ty::maps::TyCtxtAt::typeck_item_bodies
  32: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::typeck_item_bodies
  33: rustc_typeck::check_crate
  34: rustc::ty::context::TyCtxt::create_and_enter
  35: rustc_driver::driver::compile_input
  36: rustc_driver::run_compiler

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.25.0 (84203cac6 2018-03-25) running on x86_64-unknown-linux-gnu

[nikomatsakis]

Can we get a bisection?

cc @estebank -- any idea?

[nikomatsakis]

I'm going to optimistically assign @estebank -- but feel free to tell me it's not his fault. It may be mine, I touched some code there too. Mostly waiting on a bisection.

@grenewode if you are able to give https://github.com/rust-lang-nursery/cargo-bisect-rustc a try, that'd be great.

cc @rust-lang/release, otherwise.

[pietroalbini]

Bisected this, the regression appears in the #47622 rollup. The only compiler-related changes are:

• Closure argument mismatch tweaks #47573: Closure argument mismatch tweaks
• Give TargetOptions::linker a sane default value for CloudABI. #47568: Give TargetOptions::linker a sane default value for CloudABI

But the likely cause is #47573, cc @estebank @nikomatsakis

[estebank]

Will look into it.