Invaldily matching a struct from winnit makes rustc panic

[goddessfreya]

While handling input from winit I managed to stumble upon a way to make rustc panic.

I tried this code:

extern crate winit;

fn main() {
    let events_loop = winit::EventsLoop::new();
    events_loop.poll_events(|event| {
        if let winit::Event::WindowEvent { event, .. } = event {
            match event {
                winit::WindowEvent::KeyboardInput {
                    state: winit::ElementState::Pressed,
                    ..
                } => (),
            }
        }
    });
}

With this Cargo.toml:

[package]
name = "bug"
version = "0.1.0"
authors = ["Hal Gentz <zegentzy@protonmail.com>"]

[dependencies]
winit = "0.13"

and I expected to see a failed build. Instead cargo gave me this:

RUST_BACKTRACE=1 cargo run
   Compiling bug v0.1.0 (file:///home/gentz/Documents/rust/bug)
error[E0026]: variant `winit::WindowEvent::KeyboardInput` does not have a field named `state`
 --> src/main.rs:9:21
  |
9 |                     state: winit::ElementState::Pressed,
  |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ variant `winit::WindowEvent::KeyboardInput` does not have this field

thread 'main' panicked at 'no index for a field', libcore/option.rs:950:5
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
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:467
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:350
   7: rust_begin_unwind
             at libstd/panicking.rs:328
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:71
   9: core::option::expect_failed
             at libcore/option.rs:950
  10: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::field_index
  11: rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_
  12: rustc::middle::expr_use_visitor::ExprUseVisitor::walk_expr
  13: rustc::middle::expr_use_visitor::ExprUseVisitor::consume_expr
  14: rustc::middle::expr_use_visitor::ExprUseVisitor::walk_expr
  15: rustc::middle::expr_use_visitor::ExprUseVisitor::consume_expr
  16: rustc::middle::expr_use_visitor::ExprUseVisitor::walk_expr
  17: rustc::middle::expr_use_visitor::ExprUseVisitor::consume_expr
  18: rustc::middle::expr_use_visitor::ExprUseVisitor::walk_expr
  19: rustc::middle::expr_use_visitor::ExprUseVisitor::consume_expr
  20: rustc::middle::expr_use_visitor::ExprUseVisitor::consume_body
  21: rustc_typeck::check::upvar::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::analyze_closure
  22: rustc::hir::intravisit::walk_expr
  23: rustc::hir::intravisit::walk_block
  24: rustc::ty::context::tls::with_related_context
  25: rustc::infer::InferCtxtBuilder::enter
  26: rustc_typeck::check::typeck_tables_of
  27: rustc::ty::maps::<impl rustc::ty::maps::config::QueryConfig<'tcx> for rustc::ty::maps::queries::typeck_tables_of<'tcx>>::compute
  28: rustc::ty::context::tls::with_context
  29: rustc::dep_graph::graph::DepGraph::with_task_impl
  30: rustc::ty::context::tls::with_related_context
  31: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  32: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  33: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query
  34: rustc::session::Session::track_errors
  35: rustc_typeck::check::typeck_item_bodies
  36: rustc::ty::context::tls::with_context
  37: rustc::dep_graph::graph::DepGraph::with_task_impl
  38: rustc::ty::context::tls::with_related_context
  39: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  40: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  41: rustc::util::common::time
  42: rustc_typeck::check_crate
  43: rustc::ty::context::tls::enter_context
  44: <std::thread::local::LocalKey<T>>::with
  45: rustc::ty::context::TyCtxt::create_and_enter
  46: rustc_driver::driver::compile_input
  47: rustc_driver::run_compiler_with_pool
  48: syntax::with_globals
  49: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  50: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  51: rustc_driver::run
  52: rustc_driver::main
  53: std::rt::lang_start::{{closure}}
  54: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  55: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  56: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:374
             at libstd/rt.rs:58
  57: main
  58: __libc_start_main
  59: <unknown>
query stack during panic:
#0 [typeck_tables_of] processing `main`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack
error: aborting due to previous error

For more information about this error, try `rustc --explain E0026`.

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.28.0-nightly (cb20f68d0 2018-05-21) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `bug`.

To learn more, run the command again with --verbose.

Meta

rustc --version --verbose
rustc 1.28.0-nightly (cb20f68 2018-05-21)
binary: rustc
commit-hash: cb20f68
commit-date: 2018-05-21
host: x86_64-unknown-linux-gnu
release: 1.28.0-nightly
LLVM version: 6.0

[goddessfreya]

Also happens on latest nightly:
rustc 1.28.0-nightly (990d8aa 2018-05-25)
binary: rustc
commit-hash: 990d8aa
commit-date: 2018-05-25
host: x86_64-unknown-linux-gnu
release: 1.28.0-nightly
LLVM version: 6.0

[goddessfreya]

Doesn't happen on latest stable however:
rustc 1.26.0 (a775680 2018-05-07)
binary: rustc
commit-hash: a775680
commit-date: 2018-05-07
host: x86_64-unknown-linux-gnu
release: 1.26.0
LLVM version: 6.0

[goddessfreya]

Happens on latest beta:
rustc 1.27.0-beta.7 (b69d1d4 2018-05-25)
binary: rustc
commit-hash: b69d1d4
commit-date: 2018-05-25
host: x86_64-unknown-linux-gnu
release: 1.27.0-beta.7
LLVM version: 6.0

[moxian]

It got broken somewhere between

$ rustc +nightly-2018-04-12 --version --verbose
rustc 1.27.0-nightly (ad610be 2018-04-11)
binary: rustc
commit-hash: ad610be
commit-date: 2018-04-11
host: x86_64-pc-windows-gnu
release: 1.27.0-nightly
LLVM version: 6.0

and

$ rustc +nightly-2018-04-15 --version --verbose
rustc 1.27.0-nightly (bd40cbb 2018-04-14)
binary: rustc
commit-hash: bd40cbb
commit-date: 2018-04-14
host: x86_64-pc-windows-gnu
release: 1.27.0-nightly
LLVM version: 6.0

[kennytm]

cc #50643 @dlrobertson who has fixed a similar issue.

[dlrobertson]

Also seems similar to #50693. Must be another way to get through typeck without populating the field index. The fix for this should be similar to #50643 since we shouldn't make it through typeck with the wrong field names. I can look into it this evening.

[Mark-Simulacrum]

Nominating for compiler triage, though @dlrobertson may have a fix for us soon. T-3 weeks from release.

[dlrobertson]

I think I found the cause, but I'll run a few tests first. The following are the minimal repro's I could come up with for both an enum and struct.

enum SimpleEnum {
    NoState,
}

fn main() {
    let _ = |simple| {
        match simple {
            SimpleEnum::NoState {
                state: 0
            } => (),
        }
    };
}

struct SimpleStruct {
    no_state_here: u64
}

fn main() {
    let _ = |simple| {
        match simple {
            SimpleStruct {
                state: 0
            } => (),
        }
    };
}

[estebank]

The PR seems ok. It should probably be backported to beta.