Compiler panic: unexpected unsized tail: TyProjection(ProjectionTy { substs: Slice([chrono::Utc]), ...

[faern]

Just after upgrading to stable Rust 1.24, and the nightly released at approximately the same time we started experiencing compiler crashes on both Windows, Linux and macOS on both Travis/Appveyor and locally.

error: internal compiler error: librustc_trans/context.rs:446: unexpected unsized tail: TyProjection(ProjectionTy { substs: Slice([chrono::Utc]), item_def_id: DefId(13/0:83 ~ chrono[e167]::offset[0]::TimeZone[0]::Offset[0]) })

I tried this code:

I sadly don't have a minimized example triggering the bug. Because the error is happening randomly, and most often on the CI and is thus hard to reproduce. But it happens on more than one feature branch of this workspace repository: https://github.com/mullvad/mullvadvpn-app. It has for example been observed on commit 33a2edadad1c3b5fe7ea667f6b7ad4dd97c69ec3.

EDIT: Just corrected the repo url. It was wrong :P

Meta

rustc --version --verbose:

rustc 1.25.0-nightly (3ec5a99aa 2018-02-14)
binary: rustc
commit-hash: 3ec5a99aaa0084d97a9e845b34fdf03d1462c475
commit-date: 2018-02-14
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 6.0

But the same thing has happened on 1.24 stable as well.

Backtrace:
Below is from my local run on Linux. Here, a similar error can be seen for macOS on Travis: https://travis-ci.org/mullvad/mullvadvpn-app/jobs/343143393#L311

error: internal compiler error: librustc_trans/context.rs:446: unexpected unsized tail: TyProjection(ProjectionTy { substs: Slice([chrono::Utc]), item_def_id: DefId(13/0:83 ~ chrono[e167]::offset[0]::TimeZone[0]::Offset[0]) })

thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:535:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
   6: rustc_errors::Handler::bug
   7: rustc::session::opt_span_bug_fmt::{{closure}}
   8: rustc::ty::context::tls::with_opt::{{closure}}
   9: <std::thread::local::LocalKey<T>>::try_with
  10: <std::thread::local::LocalKey<T>>::with
  11: rustc::ty::context::tls::with
  12: rustc::ty::context::tls::with_opt
  13: rustc::session::opt_span_bug_fmt
  14: rustc::session::bug_fmt
  15: rustc_trans::context::CodegenCx::type_has_metadata
  16: rustc_trans::mir::place::PlaceRef::project_field::{{closure}}
  17: rustc_trans::mir::place::PlaceRef::project_field
  18: rustc_trans::mir::place::<impl rustc_trans::mir::FunctionCx<'a, 'tcx>>::trans_place
  19: rustc_trans::mir::operand::<impl rustc_trans::mir::FunctionCx<'a, 'tcx>>::trans_consume
  20: rustc_trans::mir::operand::<impl rustc_trans::mir::FunctionCx<'a, 'tcx>>::trans_operand
  21: rustc_trans::mir::rvalue::<impl rustc_trans::mir::FunctionCx<'a, 'tcx>>::trans_rvalue
  22: rustc_trans::mir::trans_mir
  23: rustc_trans::base::trans_instance
  24: rustc_trans::base::compile_codegen_unit
  25: rustc::dep_graph::graph::DepGraph::with_task_impl
  26: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::force
  27: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::try_get
  28: rustc::ty::maps::TyCtxtAt::compile_codegen_unit
  29: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::compile_codegen_unit
  30: rustc_trans::base::trans_crate
  31: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
  32: rustc_driver::driver::phase_4_translate_to_llvm
  33: rustc_driver::driver::compile_input::{{closure}}
  34: rustc::ty::context::TyCtxt::create_and_enter
  35: rustc_driver::driver::compile_input
  36: rustc_driver::run_compiler

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.25.0-nightly (3ec5a99aa 2018-02-14) running on x86_64-unknown-linux-gnu

error: Could not compile `mullvad-daemon`.

[nikomatsakis]

triage: P-high

First priority is clearly to see if we can reproduce the problem. I'll try to figure that out.

[faern]

I have tried a little bit to reduce a smaller code example. But as soon as I touch any code and recompile the error usually goes away.

[nikomatsakis]

We are hoping it's not related to #47381 -- this came up in the @rust-lang/compiler meeting. I think it was meant as a joke, but now it seems eminently plausible. =)

[pnkfelix]

Reassigning to self to attempt to reproduce (and reduce etc).

[pnkfelix]

Progress report (or lack thereof): I've made two reproduction attempts atop OS X, both based largely on the provided travis log. The main difference I noted was that I had to omit the --branch=fix-windows-warnings when cloning the repo because that branch has been deleted. But I was still able to checkout the specific commit noted in the travis log, namely commit 08f6eb436f03ba0c68d2a1e460e6ca42048124d6 before I did the submodule update and build attempt

Atop stable rustc 1.24.0 (4d90ac3 2018-02-12): no ICE observed from cargo build.

Atop nightly rustc 1.25.0-nightly (3ec5a99 2018-02-14): no ICE observed from cargo build.

I'll try with my Linux box next.

[pnkfelix]

On my Linux (Fedora) system, tried two different base commits with one fixed version of rustc:

rustc 1.25.0-nightly (27a046e 2018-02-18), commit 08f6eb436f03ba0c68d2a1e460e6ca42048124d6: no ICE observed from cargo build

rustc 1.25.0-nightly (27a046e 2018-02-18), commit 33a2edadad1c3b5fe7ea667f6b7ad4dd97c69ec3: no ICE observed from cargo build

[faern]

I should probably provide an update as well. When I reported this our CI hit the bug in like 20-50% of the builds. This number has gone down and now AppVeyor + Travis CI almost never hit the bug.

However, the bug is not gone. Because I get it now and then in my local environment. But not very often. So very hard to reproduce.

[pnkfelix]

@faern when you say the error is happening "randomly", did you mean it seems to come and go as you make changes to the code or check out different commits, but reproduces consistently with a fixed code base and compiler version?

Or did you mean that it sometimes fails to reproduce even when you leave the code base and compiler version fixed?

(In other words, is this one of those bugs that appears to depend on the phase of the moon?)