Compiler panic when using a slice pattern

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

Also reproduces on nightly

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());
}

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

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:

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

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.

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

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.

Auto merge of #59369 - oli-obk:unwrap_usICE, r=eddyb,nikomatsakis

Navigation Menu

Repository navigation

Compiler panic when using a slice pattern #59016

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compiler panic when using a slice pattern #59016

Description

Activity

jonas-schievink commented on Mar 8, 2019

Centril commented on Mar 9, 2019

oli-obk commented on Mar 14, 2019

oli-obk commented on Mar 14, 2019

oli-obk commented on Mar 22, 2019

Hythaam commented on Mar 22, 2019

oli-obk commented on Mar 22, 2019

pnkfelix commented on May 16, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions