Skip to content

ICE on use of associated constants with array expression #31267

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
sdleffler opened this issue Jan 28, 2016 · 0 comments · Fixed by #31326
Closed

ICE on use of associated constants with array expression #31267

sdleffler opened this issue Jan 28, 2016 · 0 comments · Fixed by #31326

Comments

@sdleffler
Copy link
Contributor

The following code produces an internal compiler error when compiled with rustc 1.8.0-nightly (2016-01-27) through the Rust playground:

#![feature(associated_consts)]

struct Foo;

impl Foo {
    const FOO: [i32; 3] = [0; 3];
}

fn main() {
    let foo = Foo::FOO;
}

Here's a sample of the error output from the playground:

<anon>:10:9: 10:12 warning: unused variable: `foo`, #[warn(unused_variables)] on by default
<anon>:10     let foo = Foo::FOO;
                  ^~~
error: internal compiler error: unimplemented unsupported def type in trans_local_var: AssociatedConst(DefId { krate: 0, node: DefIndex(7) => Foo::FOO })
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 'Box<Any>', ../src/libsyntax/errors/mod.rs:488
note: Run with `RUST_BACKTRACE=1` for a backtrace.

playpen: application terminated with error code 101

The error occurs regardless of the type of the array's elements. The error seems to be related to the type of array constructor used, since the following code compiles just fine:

#![feature(associated_consts)]

struct Foo;

impl Foo {
    const FOO: [i32; 3] = [0, 0, 0];
}

fn main() {
    let foo = Foo::FOO;
}

The error does not occur when associated constants are not involved:

const FOO: [i32; 3] = [0; 3];

fn main() {
    let foo = FOO;
}

Now with backtrace!

error: internal compiler error: unimplemented unsupported def type in trans_local_var: AssociatedConst(DefId { krate: 0, node: DefIndex(7) => Foo::FOO })
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 'Box<Any>', ../src/libsyntax/errors/mod.rs:488
stack backtrace:
   1:     0x7f9aa892cab0 - sys::backtrace::tracing::imp::write::hf66cd359dc225f8a0nu
   2:     0x7f9aa893375b - panicking::default_handler::_<closure>::closure.42795
   3:     0x7f9aa89332e3 - panicking::default_handler::h74bfdb4a758a82e9EFy
   4:     0x7f9aa88fcb06 - sys_common::unwind::begin_unwind_inner::h9d3a2e7a2c681f25ygt
   5:     0x7f9aa47a0ab7 - sys_common::unwind::begin_unwind::h12166797577502796958
   6:     0x7f9aa47a0ef4 - errors::Handler::bug::h7a9fc56752d25512IFd
   7:     0x7f9aa47a113f - errors::Handler::unimpl::h2fb5ffe58430b223lGd
   8:     0x7f9aa5dd2fcc - session::Session::unimpl::h27b2304e69bbb5aetFs
   9:     0x7f9aa6e7ce7b - trans::expr::trans_local_var::h3e91d61be4441e26BwE
  10:     0x7f9aa6ed2b5d - trans::expr::trans_def::had2af85c494de6b131D
  11:     0x7f9aa6ecbdd7 - trans::expr::trans_unadjusted::h3721f6e8ae7f8c49mED
  12:     0x7f9aa6e3800a - trans::expr::trans_into::ha49f8f2b3262a5d302C
  13:     0x7f9aa6f0b54a - trans::_match::mk_binding_alloca::h17168749765913251156
  14:     0x7f9aa6e1c9de - trans::base::init_local::hdd8bd44e0f714a81jKi
  15:     0x7f9aa6e34493 - trans::controlflow::trans_block::h2d1563a33f626e66GFx
  16:     0x7f9aa6e30267 - trans::base::trans_closure::h92dd74479c5c1d7dIIj
  17:     0x7f9aa6e34e0c - trans::base::trans_fn::h049c061a9498dd5duSj
  18:     0x7f9aa6e391dc - trans::base::trans_item::h90e2c2c43b81ebc8Cgk
  19:     0x7f9aa6e524cd - trans::base::TransItemsWithinModVisitor<'a, 'tcx>.Visitor<'v>::visit_item::h1a4d671566106a7fSgl
  20:     0x7f9aa6e44b53 - trans::base::trans_crate::h418c4b34389d84e1n0k
  21:     0x7f9aa8e62aa4 - driver::phase_4_translate_to_llvm::h54d254ca4986a310YXa
  22:     0x7f9aa8e5d355 - driver::phase_3_run_analysis_passes::_<closure>::closure.27398
  23:     0x7f9aa8e3ad27 - middle::ty::context::ctxt<'tcx>::create_and_enter::h2128271708407088678
  24:     0x7f9aa8e36179 - driver::phase_3_run_analysis_passes::h14773225701904660884
  25:     0x7f9aa8e08b93 - driver::compile_input::h7fb3e48531569f70xca
  26:     0x7f9aa8dfb09e - run_compiler::hf652269ac296d8cfdEc
  27:     0x7f9aa8df7901 - sys_common::unwind::try::try_fn::h11204389414678569358
  28:     0x7f9aa892a658 - __rust_try
  29:     0x7f9aa89220bb - sys_common::unwind::try::inner_try::hcce19deda87812016ct
  30:     0x7f9aa8df8130 - boxed::F.FnBox<A>::call_box::h15366779241909412522
  31:     0x7f9aa8931cd3 - sys::thread::Thread::new::thread_start::hff6465701ed07c9coCx
  32:     0x7f9aa1462181 - start_thread
  33:     0x7f9aa85a247c - __clone
  34:                0x0 - <unknown>
bors added a commit that referenced this issue Feb 4, 2016
After the truly incredible and embarrassing mess I managed to make in my last pull request, this should be a bit less messy.

Fixes #31267 - with this change, the code mentioned in the issue compiles.

Found and fixed another issue as well - constants of zero-size types, when used in ExprRepeats inside associated constants, were causing the compiler to crash at the same place as #31267. An example of this:
```

struct Bar;

const BAZ: Bar = Bar;

struct Foo([Bar; 1]);

struct Biz;

impl Biz {
    const BAZ: Foo = Foo([BAZ; 1]);
}

fn main() {
    let foo = Biz::BAZ;
    println!("{:?}", foo);
}
```
However, I'm fairly certain that my fix for this is not as elegant as it could be. The problem seems to occur only with an associated constant of a tuple struct containing a fixed size array which is initialized using a repeat expression, and when the element to be repeated provided to the repeat expression is another constant which is of a zero-sized type. The fix works by looking for constants and associated constants which are zero-width and consequently contain no data, but for which rustc is still attempting to emit an LLVM value; it simply stops rustc from attempting to emit anything. By my logic, this should work fine since the only values that are emitted in this case (according to the comments) are for closures with side effects, and constants will never have side effects, so it's fine to simply get rid of them. It fixes the error and things compile fine with it, but I have a sneaking suspicion that it could be done in a far better manner.

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant