Skip to content

Compiler panic on invalid reference type #34304

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

Closed
ninewise opened this issue Jun 16, 2016 · 5 comments
Closed

Compiler panic on invalid reference type #34304

ninewise opened this issue Jun 16, 2016 · 5 comments
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@ninewise
Copy link

ninewise commented Jun 16, 2016

Context: I was playing around with trees for a bit, when I decided the order of the children didn't matter and swapped Vecs for HashSets. However, I forgot to substitute them everywhere, which resulted in the following (minimized) code and a compiler panic.

I tried this code:

use std::collections::HashMap;
use std::collections::HashSet;

fn main() {
    let tree: HashMap<usize, HashSet<usize>> = HashMap::new();
    let size_of_1 = tree.get(&1).unwrap_or(&Vec::new()).len();
}

I expected to see this happen: the rust compiler complaining about incorrect types. After all, the &Vec::new() should've been a &HashSet::new().

Instead, this happened:

$ rustc test.rs 
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
thread 'rustc' panicked at 'index out of bounds: the len is 18 but the index is 20', src/libcollections/vec.rs:1166
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Note that using the correct intializer works, and using

use std::collections::HashMap;
use std::collections::HashSet;

struct A { a: usize }

fn main() {
    let tree: HashMap<usize, HashSet<usize>> = HashMap::new();
    let size_of_1 = tree.get(&1).unwrap_or(&A {a: 1}).len();
}

complains as expected:

$ rustc test.rs
test.rs:9:44: 9:53 error: mismatched types:
 expected `&std::collections::HashSet<usize>`,
    found `&A`
(expected struct `std::collections::HashSet`,
    found struct `A`) [E0308]
test.rs:9     let size_of_1 = tree.get(&1).unwrap_or(&A {a: 1}).len();
                                                     ^~~~~~~~~
test.rs:9:44: 9:53 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error

Meta

$ rustc --version --verbose
rustc 1.9.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.9.0

Backtrace:

$ RUST_BACKTRACE=1 rustc test.rs
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: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'index out of bounds: the len is 18 but the index is 20', src/libcollections/vec.rs:1166
stack backtrace:
   1:     0x7fedb86d7310 - <unknown>
   2:     0x7fedb86e4a0b - <unknown>
   3:     0x7fedb86e45ac - <unknown>
   4:     0x7fedb86a953f - std::sys_common::unwind::begin_unwind_inner::h39d40f52add53ef7
   5:     0x7fedb86ab628 - std::sys_common::unwind::begin_unwind_fmt::h64c0ff793199cc1b
   6:     0x7fedb86d4b21 - rust_begin_unwind
   7:     0x7fedb872730f - core::panicking::panic_fmt::h73bf9d7e8e891a73
   8:     0x7fedb87274f2 - core::panicking::panic_bounds_check::hc30e971884568c27
   9:     0x7fedb2d52bcd - <unknown>
  10:     0x7fedb2ce89e0 - rustc::infer::InferCtxt::shallow_resolve::he47cdea6677f40d2
  11:     0x7fedb2e49eb0 - <unknown>
  12:     0x7fedb2e48c27 - <unknown>
  13:     0x7fedb2e4424f - rustc::traits::fulfill::FulfillmentContext::select_where_possible::hf3fc6484c301b5bb
  14:     0x7fedb3abbc91 - <unknown>
  15:     0x7fedb3acd423 - rustc_typeck::check::FnCtxt::resolve_type_vars_if_possible::ha2a2b0468a33b7be
  16:     0x7fedb3ae1ef6 - rustc_typeck::check::demand::coerce::hd43013069440cf8a
  17:     0x7fedb3adf606 - <unknown>
  18:     0x7fedb3ade63f - <unknown>
  19:     0x7fedb3ae4b49 - <unknown>
  20:     0x7fedb3ae2ba2 - <unknown>
  21:     0x7fedb3b1a40a - rustc_typeck::check::check_decl_initializer::h130cfba0c1b76b7a
  22:     0x7fedb3b1a4d1 - rustc_typeck::check::check_decl_local::he651fa13100c1d0f
  23:     0x7fedb3b1a7c1 - rustc_typeck::check::check_stmt::h90d31dcbe73b93a2
  24:     0x7fedb3ac15a8 - <unknown>
  25:     0x7fedb3ab9239 - <unknown>
  26:     0x7fedb3ab6aec - <unknown>
  27:     0x7fedb3ab19c6 - rustc_typeck::check::check_item_body::h1895344155d5b2b2
  28:     0x7fedb3aa9881 - rustc_typeck::check::check_item_bodies::h525c1aa0e1abb529
  29:     0x7fedb3aa0def - rustc_typeck::check_crate::h0ef96f4043e1e69a
  30:     0x7fedb8c21960 - <unknown>
  31:     0x7fedb8c1fa48 - <unknown>
  32:     0x7fedb8c1c45e - <unknown>
  33:     0x7fedb8bee90f - rustc_driver::driver::compile_input::h6491aaddd9e61258
  34:     0x7fedb8bd4e74 - rustc_driver::run_compiler::h80b2ba5e4d787c5f
  35:     0x7fedb8bd22d1 - <unknown>
  36:     0x7fedb86d4aab - <unknown>
  37:     0x7fedb86d4a3d - std::sys_common::unwind::inner_try::h9eebd8dc83f388a6
  38:     0x7fedb8bd2b1a - <unknown>
  39:     0x7fedb86e2ba4 - <unknown>
  40:     0x7fedb120b3f3 - start_thread
                        at /builddir/glibc-2.23/nptl/pthread_create.c:333
  41:     0x7fedb833fbac - clone
                        at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
  42:                0x0 - <unknown>
@jonas-schievink
Copy link
Contributor

Probably autoderef, might be fixed on nightly

@retep998
Copy link
Member

Still occurs on nightly according to playpen.

@jonas-schievink
Copy link
Contributor

I think playpen's nightly is outdated for some reason. The current nightly gives the expected error and no ICE.

@TimNN
Copy link
Contributor

TimNN commented Jun 16, 2016

The nightly on playpen is 2016-05-18, see rust-lang/rust-playpen#215

@apasel422 apasel422 added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Jun 17, 2016
@nagisa
Copy link
Member

nagisa commented Jun 29, 2016

Same as #34428, I think. The code now works on nightly, and the other issue has better backtrace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

7 participants