Compiler panic when using a slice pattern

[jakoschiko]

I got thread 'rustc' panicked at 'expected `LazyConst` to contain a usize', src/libcore/option.rs:1038:5 when using a slice pattern.

Example code:

trait Gen<T> {
    fn gen(&self) -> T;
}

impl<T, F: Fn() -> T> Gen<T> for F {
    fn gen(&self) -> T {
        self()
    }
}

fn byte_gen() -> impl Gen<u8> {
    || 42
}

fn array_3_gen<T>(elem_gen: impl Gen<T>) -> impl Gen<[T; 3]> {
    move || [elem_gen.gen(), elem_gen.gen(), elem_gen.gen()]
}

fn main() {
    // let bytes = array_3_gen(byte_gen()).gen(); // no panic
    let [a, b, c] = array_3_gen(byte_gen()).gen(); // panic!
}

Compiler output:

$ cargo build
   Compiling foo v0.1.0 (/home/rustlover/code/rust/foo)
thread 'rustc' panicked at 'expected `LazyConst` to contain a usize', src/libcore/option.rs:1038:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

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.33.0 (2aa4c46cf 2019-02-28) 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 `foo`.

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

Compiler version:

$ rustc --version --verbose
rustc 1.33.0 (2aa4c46cf 2019-02-28)
binary: rustc
commit-hash: 2aa4c46cfdd726e97360c2734835aa3515e8c858
commit-date: 2019-02-28
host: x86_64-unknown-linux-gnu
release: 1.33.0
LLVM version: 8.0

Backtrace:

stack backtrace:
   0:     0x7f2ec5eff793 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::hf8722b0178fb1b63
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1:     0x7f2ec5ef7c48 - std::sys_common::backtrace::_print::hc40139e5f1d656ee
                               at src/libstd/sys_common/backtrace.rs:70
   2:     0x7f2ec5efb922 - std::panicking::default_hook::{{closure}}::h993d43465919c16a
                               at src/libstd/sys_common/backtrace.rs:58
                               at src/libstd/panicking.rs:200
   3:     0x7f2ec5efb694 - std::panicking::default_hook::h73d2c2ec3d9ba5a4
                               at src/libstd/panicking.rs:215
   4:     0x7f2ec19ae31f - rustc::util::common::panic_hook::he83c1d31ee2662ae
   5:     0x7f2ec5efc109 - std::panicking::rust_panic_with_hook::h744417edfe714d72
                               at src/libstd/panicking.rs:482
   6:     0x7f2ec5efbbb1 - std::panicking::continue_panic_fmt::h3557b3c3fa21b47b
                               at src/libstd/panicking.rs:385
   7:     0x7f2ec5efba95 - rust_begin_unwind
                               at src/libstd/panicking.rs:312
   8:     0x7f2ec5f25cac - core::panicking::panic_fmt::h74ee8034b317ceed
                               at src/libcore/panicking.rs:85
   9:     0x7f2ec5f25dc2 - core::option::expect_failed::hbc312d76c0b547f0
                               at src/libcore/option.rs:1038
  10:     0x7f2ec3e6b549 - rustc_typeck::check::_match::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::check_pat_walk::h71a84aaf4490c100
  11:     0x7f2ec3eaba89 - rustc_typeck::check::FnCtxt::check_decl_local::h6cd4344ce4d41c65
  12:     0x7f2ec3eabb97 - rustc_typeck::check::FnCtxt::check_stmt::h75310cceec23d2e4
  13:     0x7f2ec3eac00a - rustc_typeck::check::FnCtxt::check_block_with_expected::h3bfd8e88110fd9f1
  14:     0x7f2ec3ea11ff - rustc_typeck::check::FnCtxt::check_expr_kind::h375a1326cead31d6
  15:     0x7f2ec3ea0f90 - rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs::h2ae4f0da43669b47
  16:     0x7f2ec3ea0139 - rustc_typeck::check::FnCtxt::check_return_expr::hd9c52b2ec7e22022
  17:     0x7f2ec3e9054c - rustc_typeck::check::check_fn::h3d19cb057f16bf14
  18:     0x7f2ec3fbd982 - rustc::ty::context::GlobalCtxt::enter_local::hc07cc749cef8eb1a
  19:     0x7f2ec3e8f1ef - rustc_typeck::check::typeck_tables_of::hb454bb4b066528cf
  20:     0x7f2ec190510c - rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute::hc5eac1e163f72b87
  21:     0x7f2ec1580276 - rustc::dep_graph::graph::DepGraph::with_task_impl::h0b7551d53ac8e004
  22:     0x7f2ec1776a8c - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_with::h7b6cd2762bee21db
  23:     0x7f2ec184a83e - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query::h001f5d6204e1c3a1
  24:     0x7f2ec3f0f30c - rustc::session::Session::track_errors::h6e57172230d7fa6d
  25:     0x7f2ec3e8ecde - rustc_typeck::check::typeck_item_bodies::hfbbc2617bda77f6d
  26:     0x7f2ec3dcb446 - rustc::ty::query::__query_compute::typeck_item_bodies::hc29cdeb125e5955e
  27:     0x7f2ec3f40bf8 - rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_item_bodies<'tcx>>::compute::h93523efffb25e349
  28:     0x7f2ec3f19ca5 - rustc::dep_graph::graph::DepGraph::with_task_impl::h203bcc11c6603b1b
  29:     0x7f2ec3f9b2b7 - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_with::hdf3aec97cbb89d46
  30:     0x7f2ec3d556a4 - rustc::util::common::time::h3c5cedd106c5f0e8
  31:     0x7f2ec3f37ded - rustc_typeck::check_crate::hba6d5def7fb55eec
  32:     0x7f2ec62a2b85 - <std::thread::local::LocalKey<T>>::with::hcaf51866d9f51790
  33:     0x7f2ec621dc2e - rustc::ty::context::TyCtxt::create_and_enter::hf8fff029ce04ca77
  34:     0x7f2ec62d5414 - rustc_driver::driver::compile_input::h65aaa3180b3e84e4
  35:     0x7f2ec6230dd0 - rustc_driver::run_compiler_with_pool::h7731b79ae97e4d21
  36:     0x7f2ec623cc05 - <scoped_tls::ScopedKey<T>>::set::h10a9d6691c6667b2
  37:     0x7f2ec622fc1a - rustc_driver::run_compiler::hccae18cc847caa81
  38:     0x7f2ec623cdba - <scoped_tls::ScopedKey<T>>::set::h71212949a1d6fa63
  39:     0x7f2ec62ae802 - std::sys_common::backtrace::__rust_begin_short_backtrace::h76607ec057ea37b9
  40:     0x7f2ec5f0d529 - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:92
  41:     0x7f2ec62c5fa0 - <F as alloc::boxed::FnBox<A>>::call_box::h33b88f71d009a576
  42:     0x7f2ec5f0c2ed - std::sys::unix::thread::Thread::new::thread_start::h6fb76bcf544b6181
                               at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/liballoc/boxed.rs:744
                               at src/libstd/sys_common/thread.rs:14
                               at src/libstd/sys/unix/thread.rs:81
  43:     0x7f2ec5c7f6da - start_thread
  44:     0x7f2ec559c88e - __clone
  45:                0x0 - <unknown>
query stack during panic:
#0 [typeck_tables_of] processing `main`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack

[jonas-schievink]

Also reproduces on nightly

[Centril]

Reduced:

trait Gen<T> {
    fn gen(x: Self) -> T;
}

impl<T, F: FnOnce() -> T> Gen<T> for F {
    fn gen(x: Self) -> T {
        x()
    }
}

fn array() -> impl Gen<[(); 0]> {
    move || []
}

fn main() {
    let [] = Gen::gen(array());
}

[oli-obk]

Without closures:

trait Gen<T> {
    fn gen(x: Self) -> T;
}

struct A;

impl Gen<[(); 0]> for A {
    fn gen(x: Self) -> [(); 0] {
        []
    }
}

fn array() -> impl Gen<[(); 0]> {
    A
}

fn main() {
    let [] = Gen::gen(array());
}

I believe the issue is that we aren't normalizing constants before trying to access their content. This makes me wonder if all uses of unwrap_usize are actually wrong and should be attempting to evaluate in case of Unevaluated

[oli-obk]

After #59178 this is actually doable in a reasonable way. Marking as blocked

[oli-obk]

Basically all the unwrap_usize calls like

rust/src/librustc_typeck/check/_match.rs

Line 399 in ad8a3eb

let size = size.unwrap_usize(tcx);

may encounter this ICE.

I believe that the problem is that structurally_resolved_type doesn't normalize its types. So while it resolves Self to [(); 0] in the above example, the 0 is still an unevaluated constant.

We basically have two options now:

1. remove unwrap_usize and instead create an evaluate_usize method that takes a tcx and tries to evaluate the constant
2. normalize types in more places (I'm not sure if that will cause unintended side effects or slowdowns)

[Hythaam]

I'm not sure if this is the same error, but I'm getting the same message on this code:

fn testfn(_arr: &mut [();0]) {}

trait TestTrait {
    fn method() {
}

impl TestTrait for [(); 0] {
    fn method() {
        let mut arr: Self = [(); 0];
        testfn(&mut arr);
    }
}

fn main() {}

Everything compiles fine when I remove the Self from let mut arr: Self = [(); 0]; line.

Let me know if you'd like more details or the stack trace; If it's unrelated, I can also submit it as a new bug, but it sounds like this has the same root cause.

[oli-obk]

Your example is unrelated to slice patterns, but a symptom of the same unwrap_usize problem.

[pnkfelix]

triage: Downgrading priority to P-medium. It seems like this problem, while potentially annoying, is not masking some underlying soundness hole or serious expressiveness bug.