Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler panic when using a slice pattern #59016

Closed
jakoschiko opened this issue Mar 8, 2019 · 8 comments · Fixed by #59369
Closed

Compiler panic when using a slice pattern #59016

jakoschiko opened this issue Mar 8, 2019 · 8 comments · Fixed by #59369
Assignees
Labels
C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jakoschiko
Copy link
Contributor

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 jonas-schievink added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Mar 8, 2019
@jonas-schievink
Copy link
Contributor

Also reproduces on nightly

@Centril
Copy link
Contributor

Centril commented Mar 9, 2019

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

@pnkfelix pnkfelix added the P-high High priority label Mar 11, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Mar 14, 2019

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

This comment has been minimized.

@oli-obk oli-obk added the S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. label Mar 14, 2019
@oli-obk oli-obk removed the S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. label Mar 22, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Mar 22, 2019

Basically all the unwrap_usize calls like

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
Copy link

Hythaam commented Mar 22, 2019

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
Copy link
Contributor

oli-obk commented Mar 22, 2019

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

@pnkfelix
Copy link
Member

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.

@pnkfelix pnkfelix added P-medium Medium priority and removed P-high High priority labels May 16, 2019
bors added a commit that referenced this issue Aug 5, 2019
`unwrap_usize` should at least try to evaluate the underlying constant

r? @eddyb

fixes #59016

I know that I'm still using `ParamEnv` wrongly, but that's a preexisting issue not amplified by this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants