ICE using associated constant in generic type

[Michael-F-Bryan]

I'd like to use an associated constant when telling arrayvec::ArrayVec how big the underlying array should be and encountered an ICE while running the following code:

use arrayvec::ArrayVec;

pub struct MultiDriver<D: ?Sized> {
    drivers: ArrayVec<[Driver<D>; MultiDriver::<D>::MAX_DRIVERS]>,
}

impl<D: ?Sized> MultiDriver<D> {
    pub const MAX_DRIVERS: usize = 10;

    pub fn new() -> MultiDriver<D> {
        MultiDriver {
            drivers: ArrayVec::new(),
        }
    }

    pub fn push_driver(&mut self, driver: Driver<D>) {
        self.drivers.push(driver);
    }
}

struct Driver<D>(D);

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
error: internal compiler error: src/librustc/ty/subst.rs:557: type parameter `D/#0` (D/0) out of range when substituting (root type=Some(D)) substs=[]

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:584:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.lhy31512.workers.dev-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.lhy31512.workers.dev-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: rustc::util::common::panic_hook
   7: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:481
   8: std::panicking::begin_panic
   9: rustc_errors::Handler::span_bug
  10: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  11: rustc::ty::context::tls::with_opt::{{closure}}
  12: rustc::ty::context::tls::with_context_opt
  13: rustc::ty::context::tls::with_opt
  14: rustc::util::bug::opt_span_bug_fmt
  15: rustc::util::bug::span_bug_fmt
  16: <rustc::ty::subst::SubstFolder as rustc::ty::fold::TypeFolder>::fold_ty
  17: <smallvec::SmallVec<A> as core::iter::traits::collect::FromIterator<<A as smallvec::Array>::Item>>::from_iter
  18: rustc::ty::fold::TypeFoldable::fold_with
  19: rustc::traits::codegen::<impl rustc::ty::context::TyCtxt>::subst_and_normalize_erasing_regions
  20: rustc_mir::interpret::eval_context::InterpCx<M>::resolve
  21: rustc_mir::interpret::operand::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::eval_const_to_op
  22: rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::run
  23: rustc_mir::const_eval::eval_body_using_ecx
  24: rustc_mir::const_eval::const_eval_raw_provider
  25: rustc::ty::query::__query_compute::const_eval_raw
  26: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::const_eval_raw>::compute
  27: rustc::dep_graph::graph::DepGraph::with_task_impl
  28: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  29: rustc_mir::const_eval::const_eval_provider
  30: rustc::ty::query::__query_compute::const_eval
  31: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::const_eval>::compute
  32: rustc::dep_graph::graph::DepGraph::with_task_impl
  33: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  34: <rustc::traits::project::AssocTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_const
  35: rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable for &rustc::ty::TyS>::super_fold_with
  36: <rustc::traits::project::AssocTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_ty
  37: <smallvec::SmallVec<A> as core::iter::traits::collect::FromIterator<<A as smallvec::Array>::Item>>::from_iter
  38: rustc::ty::fold::TypeFoldable::fold_with
  39: rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable for &rustc::ty::TyS>::super_fold_with
  40: <rustc::traits::project::AssocTypeNormalizer as rustc::ty::fold::TypeFolder>::fold_ty
  41: rustc::traits::project::normalize
  42: rustc_typeck::check::FnCtxt::normalize_associated_types_in
  43: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  44: rustc::ty::context::GlobalCtxt::enter_local
  45: rustc_typeck::check::wfcheck::check_item_well_formed
  46: rustc::ty::query::__query_compute::check_item_well_formed
  47: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::check_item_well_formed>::compute
  48: rustc::dep_graph::graph::DepGraph::with_task_impl
  49: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  50: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  51: std::panicking::try::do_call
  52: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:82
  53: rustc_data_structures::sync::par_for_each_in
  54: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:82
  55: rustc::hir::Crate::par_visit_all_item_likes
  56: rustc::util::common::time
  57: rustc_typeck::check_crate
  58: rustc_interface::passes::analysis
  59: rustc::ty::query::__query_compute::analysis
  60: rustc::dep_graph::graph::DepGraph::with_task_impl
  61: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  62: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  63: rustc_interface::passes::create_global_ctxt::{{closure}}
  64: rustc_interface::interface::run_compiler_in_existing_thread_pool
  65: std::thread::local::LocalKey<T>::with
  66: scoped_tls::ScopedKey<T>::set
  67: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
query stack during panic:
#0 [const_eval_raw] const-evaluating `MultiDriver::drivers::{{constant}}#0`
#1 [const_eval] const-evaluating + checking `MultiDriver::drivers::{{constant}}#0`
#2 [check_item_well_formed] processing `MultiDriver`
#3 [analysis] running analysis passes on this crate
end of query stack
error[E0277]: the size for values of type `D` cannot be known at compilation time
  --> src/lib.rs:16:5
   |
16 | /     pub fn push_driver(&mut self, driver: Driver<D>) {
17 | |         self.drivers.push(driver);
18 | |     }
   | |_____^ doesn't have a size known at compile-time
   |
   = help: the trait `std::marker::Sized` is not implemented for `D`
   = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
   = help: consider adding a `where D: std::marker::Sized` bound
note: required by `Driver`
  --> src/lib.rs:21:1
   |
21 | struct Driver<D>(D);
   | ^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0277`.

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.38.0-nightly (83e4eed16 2019-07-14) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `playground`.

To learn more, run the command again with --verbose.


To learn more, run the command again with --verbose.

[hellow554]

Minified:

pub struct MultiDriver<D: ?Sized> {
    d: [std::marker::PhantomData<D>; MultiDriver::<D>::MAX_DRIVERS],
}

impl<D: ?Sized> MultiDriver<D> {
    const MAX_DRIVERS: usize = 10;
}

[nikomatsakis]

Compiler team triage:

Marking as medium for now but indicating "needs mentor". This is a fairly basic example, so it would be good to figure out why it doesn't work and get it working.

[lcnr]

Requires lazy normalization of constants, see #72219 for more details

[JohnTitor]

Triage:

This is no longer ICE even with the const_generics feature flag on the latest nightly: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=cc818f5389feef764f2689cfdeabfa03

[varkor]

I think we already have several tests for this case already, so it should be safe to close now.