ICE with associated constants

[petrochenkov]

While trying to migrate i32::BYTES and friends to associated constants I have encountered this ICE. It's caused by some code in libstd, but the precise location is not clear.
The branch reproducing the ICE can be found here: https://github.com/petrochenkov/rust/tree/primod

cc @quantheory

petrochenkov@______________:~/rust$ RUST_BACKTRACE=1 make rustc-stage1
cfg: version 1.1.0-dev (d4cedea80 2015-04-29) (built 2015-04-29)
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: enabling debug assertions (CFG_ENABLE_DEBUG_ASSERTIONS)
cfg: enabling debuginfo (CFG_ENABLE_DEBUGINFO)
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: good valgrind for x86_64-unknown-linux-gnu is 1
cfg: using CC=gcc (CFG_CC)
cfg: enabling valgrind run-pass tests (CFG_ENABLE_VALGRIND_RPASS)
cfg: valgrind-rpass command set to "/usr/bin/valgrind" --error-exitcode=100 --fair-sched=try --quiet --soname-synonyms=somalloc=NONE --suppressions=/home/petrochenkov/rust/src/etc/x86.supp  --tool=memcheck --leak-check=full
cfg: no pandoc found, omitting PDF and EPUB docs
rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd
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 'path not fully resolved: PathResolution { base_def: DefPrimTy(TyUint(usize)), last_private: LastMod(AllPublic), depth: 1 }', /home/rustbuild/src/rust-buildbot/slave/snap3-linux/build/src/librustc/middle/def.rs:81

stack backtrace:
   1:     0x2ba1ec043f49 - sys::backtrace::write::h067c01906fdf3adcBYr
   2:     0x2ba1ec048926 - panicking::on_panic::h6fb702bb3fef68b4pow
   3:     0x2ba1ec025db2 - rt::unwind::begin_unwind_inner::h48266f2af204eb4bz3v
   4:     0x2ba1ec026927 - rt::unwind::begin_unwind_fmt::h04658be8f2a38794F2v
   5:     0x2ba1eab43d55 - middle::const_eval::eval_const_expr_partial::hea9baa0e05ef4477cki
   6:     0x2ba1eab4167b - middle::const_eval::eval_const_expr_partial::hea9baa0e05ef4477cki
   7:     0x2ba1eab4107c - middle::const_eval::eval_const_expr_partial::hea9baa0e05ef4477cki
   8:     0x2ba1ea952b85 - astconv::ast_ty_to_ty::h97d439ea4783dc9cnSv
   9:     0x2ba1ea9d011a - iter::Map<I, F>.Iterator::next::h15925606040031353243
  10:     0x2ba1ea9c49ea - collect::convert_struct::hecd7620d2481fe2eTVx
  11:     0x2ba1ea9b465d - collect::convert_item::hfde15e9c0c9154957Ax
  12:     0x2ba1ea9ba9a2 - visit::walk_item::h8692254520880490375
  13:     0x2ba1ea9ba9ad - visit::walk_item::h8692254520880490375
  14:     0x2ba1ea9ba9ad - visit::walk_item::h8692254520880490375
  15:     0x2ba1ea9fce41 - check_crate::closure.38342
  16:     0x2ba1ea9fadfb - check_crate::ha670ea092e3c1178tCC
  17:     0x2ba1ea5aca88 - driver::phase_3_run_analysis_passes::hcf43fee03d96b08dtGa
  18:     0x2ba1ea58ea30 - driver::compile_input::h2d039586ffa6a9e4Qba
  19:     0x2ba1ea646871 - run_compiler::h4f34718c5e17403165b
  20:     0x2ba1ea6440c2 - boxed::F.FnBox<A>::call_box::h10040685102554793607
  21:     0x2ba1ea643679 - rt::unwind::try::try_fn::h2545211264873891294
  22:     0x2ba1ec04de18 - rust_try_inner
  23:     0x2ba1ec04de05 - rust_try
  24:     0x2ba1ea643920 - boxed::F.FnBox<A>::call_box::h13618416845398747240
  25:     0x2ba1ec0477c1 - sys::thread::Thread::new::thread_start::ha1bf268dbc858fc809u
  26:     0x2ba1ecd01181 - start_thread
  27:     0x2ba1ed93947c - __clone
  28:                0x0 - <unknown>

[quantheory]

I don't yet know what the exact problem is, but I think that it is related to this failing test case:

// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

#![feature(associated_consts)]

trait AsFixedSizeArray: Sized {
    const SIZE: usize;
    unsafe fn as_fixed_size_array(&self)
                                  -> &[u8; <Self as AsFixedSizeArray>::SIZE];
}

impl AsFixedSizeArray for u8 {
    const SIZE: usize = 1;
    fn as_fixed_size_array(&self)
                           -> &[u8; <Self as AsFixedSizeArray>::SIZE] {
        &[*self]
    }
}

fn main() {
    assert_eq!([1u8], *(1u8).as_fixed_size_array());
}

Output:

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 'called `Option::unwrap()` on a `None` value', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/option.rs:362

stack backtrace:
   1:      0x360164ec0b9 - sys::backtrace::write::h0bd0381a7c6d019fBYr
   2:      0x360164f3e46 - panicking::on_panic::h953134dfac303ab1pow
   3:      0x360164b5ba2 - rt::unwind::begin_unwind_inner::hd1b458e2307f3d05z3v
   4:      0x360164b6967 - rt::unwind::begin_unwind_fmt::h08053ed3951de550F2v
   5:      0x360164f3a26 - rust_begin_unwind
   6:      0x36016540084 - panicking::panic_fmt::hf5d8479bf55b3fa2NKy
   7:      0x3601653ec64 - panicking::panic::h824ffaba30018d8bkJy
   8:      0x360145fd848 - middle::ty::TraitRef<'tcx>::self_ty::h551bfe30dbbedbc9xr3
   9:      0x36014627172 - middle::traits::select::SelectionContext<'cx, 'tcx>::candidate_from_obligation::hf8ada0827e1be47bteR
  10:      0x360144ff3ed - middle::traits::select::SelectionContext<'cx, 'tcx>::select::h377fd22a5284042fsSQ
  11:      0x360144f973a - middle::const_eval::resolve_trait_associated_const::h9711fd07dfd9af7cQMi
  12:      0x360144acdf8 - middle::const_eval::eval_const_expr_partial::hb8dc4544c452182dcki
  13:      0x36015ce0c35 - astconv::ast_ty_to_ty::h71cca4fc3e245676nSv
  14:      0x36015ce0dac - astconv::ast_ty_to_ty::h71cca4fc3e245676nSv
  15:      0x36015d31a4d - astconv::convert_ty_with_lifetime_elision::ha9a5c36346b84adeBQu
  16:      0x36015d3b8d6 - astconv::ty_of_method_or_bare_fn::h225734b640577932p8v
  17:      0x36015d58b6e - collect::convert_method::hd7d7ee3346f6b3e6zlx
  18:      0x36015d43f38 - collect::convert_item::hd27f0bc8c9c983e37Ax
  19:      0x36015d8baf6 - check_crate::closure.38750
  20:      0x36015d89abb - check_crate::h8249ae25e4dcf889tCC
  21:      0x36016a2f728 - driver::phase_3_run_analysis_passes::h5acb8c02893af881tGa
  22:      0x36016a10fac - driver::compile_input::h2d4d7c29076e9ffaQba
  23:      0x36016aca2f1 - run_compiler::h39664fd458db49c365b
  24:      0x36016ac7b42 - boxed::F.FnBox<A>::call_box::h8536945657960310400
  25:      0x36016ac70e9 - rt::unwind::try::try_fn::h4867300882306443046
  26:      0x36016567788 - rust_try_inner
  27:      0x36016567775 - rust_try
  28:      0x36016ac7390 - boxed::F.FnBox<A>::call_box::h18199782063315395191
  29:      0x360164f2be1 - sys::thread::Thread::new::thread_start::h92b0e1bfe7b243d409u
  30:      0x3601059c68b - <unknown>
  31:      0x3601615032c - clone
  32:                0x0 - <unknown>

There are a few similar cases that I will open bugs for, some of which have a common cause, I think.

[quantheory]

Hmm, I've sort-of figured out how to implement a fix, but it will take a bit more time. The problem is that:

1. We need to figure out what types are present in order to do coherence checks.
2. We need to do coherence checks in order to resolve associated consts that might depend on traits.
3. We need to resolve associated consts in order to know what array types are present.

The most obvious solution is to do something similar to how associated types are currently handled using projections. (I think that @nikomatsakis mentioned something about this a while back.) I don't think that associated types are doing the right thing in all situations, but moving in that direction we could probably get a lot more code to compile.

[petrochenkov]

@quantheory
Closing, the branch compiles now. Whatever the issue was you've fixed it in one of the recent PRs.