Compiler panic while compiling iterator with match

[Skyfold]

In all honesty this code is a bit contrived and nonsensical. I just happen to run into this panic while coding. It seems to have something do with both the .iter() and match on u64::max_value().

I tried this code:

use std::slice::Iter;

#[derive(Clone, Copy)]
pub struct Word8([usize; 8]);

impl Word8 {
    pub fn iter(&self) -> Iter<usize> {
        self.0.iter()
    }
}

fn bug(word: Word8) -> u64 {
    word.iter().for_each(|wire| match 0 {
        u64::max_value() => 0,
    });
    0
}

https://play.rust-lang.org/?version=beta&mode=debug&edition=2015&gist=4280b3c650ed29ba3645dc6f2a348ef5

https://gist.github.com/4280b3c650ed29ba3645dc6f2a348ef5

I expected to see this happen: give me an error about why this is wrong.

Instead, this happened: got panic

Meta

rustc --version --verbose:

rustc 1.30.0-beta.17 (f33946f 2018-10-23)
binary: rustc
commit-hash: f33946f
commit-date: 2018-10-23
host: x86_64-unknown-linux-gnu
release: 1.30.0-beta.17
LLVM version: 8.0

Backtrace:

error[E0601]: `main` function not found in crate `tmp`
  |
  = note: consider adding a `main` function to `tmp.rs`

error[E0164]: expected tuple struct/variant, found method `<u64>::max_value`
  --> tmp.rs:14:9
   |
14 |         u64::max_value() => 0,
   |         ^^^^^^^^^^^^^^^^ not a tuple variant or struct

error[E0308]: mismatched types
  --> tmp.rs:13:33
   |
13 |       word.iter().for_each(|wire| match 0 {
   |  _________________________________^
14 | |         u64::max_value() => 0,
15 | |     });
   | |_____^ expected (), found integral variable
   |
   = note: expected type `()`
              found type `{integer}`

error: internal compiler error: librustc/middle/mem_categorization.rs:1302: tuple struct pattern didn't resolve to variant or struct Method(DefId(2/0:9137 ~ core[396f]::num[0]::{{impl}}[15]::max_value[0]))
  --> tmp.rs:14:9
   |
14 |         u64::max_value() => 0,
   |         ^^^^^^^^^^^^^^^^

thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:525:9
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:481
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::span_bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::span_bug_fmt
  14: rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_
  15: rustc::middle::expr_use_visitor::ExprUseVisitor::walk_expr
  16: rustc::middle::expr_use_visitor::ExprUseVisitor::consume_expr
  17: rustc_typeck::check::upvar::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::analyze_closure
  18: <rustc_typeck::check::upvar::InferBorrowKindVisitor<'a, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  19: rustc::hir::intravisit::walk_expr
  20: rustc::hir::intravisit::walk_expr
  21: rustc::ty::context::tls::with_related_context
  22: rustc::infer::InferCtxtBuilder::enter
  23: rustc_typeck::check::typeck_tables_of
  24: rustc::ty::query::__query_compute::typeck_tables_of
  25: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute
  26: rustc::dep_graph::graph::DepGraph::with_task_impl
  27: rustc::ty::context::tls::with_related_context
  28: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  30: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query
  31: rustc_typeck::check::typeck_item_bodies
  32: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_item_bodies<'tcx>>::compute
  33: rustc::dep_graph::graph::DepGraph::with_task_impl
  34: rustc::ty::context::tls::with_related_context
  35: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  36: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  37: rustc_typeck::check_crate
  38: rustc::ty::context::tls::enter_context
  39: <std::thread::local::LocalKey<T>>::with
  40: rustc::ty::context::TyCtxt::create_and_enter
  41: rustc_driver::driver::compile_input
  42: rustc_driver::run_compiler_with_pool
  43: rustc_driver::driver::spawn_thread_pool
  44: rustc_driver::run_compiler
  45: <scoped_tls::ScopedKey<T>>::set
  46: syntax::with_globals
  47: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:103
  48: rustc_driver::run
  49: rustc_driver::main
  50: std::rt::lang_start::{{closure}}
  51: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  52: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:103
  53: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  54: main
  55: __libc_start_main
  56: <unknown>
query stack during panic:
#0 [typeck_tables_of] processing `bug`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack
error: aborting due to 4 previous errors

Some errors occurred: E0164, E0308, E0601.
For more information about an error, try `rustc --explain E0164`.

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.30.0-beta.17 (f33946f81 2018-10-23) running on x86_64-unknown-linux-gnu

[oli-obk]

While officially tracked by #24111 I'll abuse this issue as a more targeted tracking issue just for the const fn calls in patterns feature.

The code is actually supposed to compile successfully. there's not supposed to be any difference between tuple struct constructors and const fns except that you can't have patterns as the arguments of const fns. The args need to be expressions.

In the process of implementing this in a reasonable way we should explore whether it makes sense to have to prefix const fn patterns with const.

[oli-obk]

Tracking now in #57240