`size_of` of associated type ICEs

[kennytm]

Originally reported in #43355, which should be a different bug from the main report.

trait Trait1 {
    type Output;
}
fn f<T: Trait1>() {
    ::std::mem::size_of::<T::Output>();
}
fn main() {}

On nightly, crashes with:

$ RUST_BACKTRACE=1 rustc 1.rs
error: internal compiler error: src/librustc/infer/mod.rs:573: Encountered errors `[FulfillmentError(Obligation(predicate=Binder(TraitPredicate(<T as Trait1>)),depth=0),Unimplemented)]` resolving bounds after type-checking

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.20.0-nightly (582af6e1a 2017-07-19) running on x86_64-apple-darwin

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:437:8
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   8: rustc::session::span_bug_fmt
   9: <&'gcx rustc::ty::TyS<'gcx> as rustc::infer::TransNormalize<'gcx>>::trans_normalize
  10: rustc::infer::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'tcx>>::normalize_associated_type_in_env
  11: rustc::ty::layout::Layout::compute_uncached
  12: rustc::ty::util::layout_raw
  13: rustc::ty::maps::<impl rustc::ty::maps::queries::layout_raw<'tcx>>::try_get
  14: rustc::ty::maps::TyCtxtAt::layout_raw
  15: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::layout_raw
  16: rustc_const_eval::eval::eval_const_expr_partial::{{closure}}
  17: rustc_const_eval::eval::eval_const_expr_partial
  18: rustc_const_eval::eval::eval_const_expr_partial
  19: rustc_const_eval::eval::eval_const_expr_partial
  20: rustc_const_eval::eval::eval_const_expr_partial
  21: rustc_const_eval::eval::ConstContext::eval
  22: <rustc_passes::consts::CheckCrateVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_expr
  23: <rustc_passes::consts::CheckCrateVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_expr
  24: <rustc_passes::consts::CheckCrateVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_nested_body
  25: rustc_passes::consts::check_crate
  26: rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}
  27: rustc_driver::driver::phase_3_run_analysis_passes
  28: rustc_driver::driver::compile_input
  29: rustc_driver::run_compiler

Does not crash with 1.20.0-beta.1 (e93aa3aa8 2017-07-18).

cc @eddyb #42859, which is relevant and is inside the commit range e93aa3a...582af6e.

[eddyb]

Hmm, the fact normalize_projections_in uses drain_fulfillment_cx_or_panic which panics, is unfortunate. What I would want to happen is to get the unmodified value if there are any errors.

cc @arielb1 Was the layout code always going to ICE like that? Or did it get changed? Transmute checking uses it and that shouldn't ever ICE.

[eddyb]

The snippet below gives the right error, so likely I used the wrong way to get the layout.

fn f<T: ::std::ops::Neg>(x: T) -> T::Output {
    ::std::mem::transmute(x)
}

[qnighy]

Duplicate of #43394?

[eddyb]

@qnighy Yes, but the other way around, #43394 is a (more recent) duplicate of this issue.

[arielb1]

The problem is that const_eval is calling for layout while throwing the param-env on the floor, so the types are not known to be WF:

rust/src/librustc_const_eval/eval.rs

Line 345 in 5669c99

let layout_of = |ty: Ty<'tcx>| {

            let layout_of = |ty: Ty<'tcx>| {
                ty.layout(tcx, ty::ParamEnv::empty(traits::Reveal::All))
                    .map_err(|err| {
                        ConstEvalErr { span: e.span, kind: LayoutError(err) }
                    })
            };

It should either use the "correct" param env (so that the types will still be WF) or it should bail out when it sees a generic type.

[eddyb]

Ah, I see, I'll try to plumb the ParamEnv through it (this is the rustc_passes::consts code triggering evaluation in regular functions to emit certain warnings).