Internal compiler error, broken MIR, in latest Rust nightly

[timvisee]

The latest Rust nightly (rustc 1.31.0-nightly (1dceaddfb 2018-10-17)) has introduced an compiler error, that causes the compiler to crash when compiling nalgebra. I'm not entirely sure posting this here is correct. The problem was introduced in a minor Rust nightly compiler update, and if the code is bad, I don't think the Rust compiler should crash the way it does now.

Here is a snippet of errors that are coming up (complete log):

error: internal compiler error: broken MIR in DefId(0/0:8133 ~ nalgebra[ff9d]::base[0]::swizzle[0]::{{impl}}[0]::xx[0]) (const base::construction::<impl base::matrix::Matrix<N, base::dimension::U2, base::dimension::U1, <base::default_allocator::DefaultAllocator as base::allocator::Allocator<N, base::dimension::U2>>::Buffer>>::new): bad constant user type FnDef(DefId(0/0:8339 ~ nalgebra[ff9d]::base[0]::construction[0]::{{impl}}[47]::new[0]), Canonical { variables: [CanonicalVarInfo { kind: Ty(General) }, CanonicalVarInfo { kind: Ty(General) }, CanonicalVarInfo { kind: Ty(General) }], value: UserSubsts { substs: [_], user_self_ty: Some(UserSelfTy { impl_def_id: DefId(0/0:8338 ~ nalgebra[ff9d]::base[0]::construction[0]::{{impl}}[47]), self_ty: base::matrix::Matrix<_, base::dimension::U2, base::dimension::U1, base::matrix_array::MatrixArray<_, base::dimension::U2, base::dimension::U1>> }) } }) vs fn(N, N) -> base::matrix::Matrix<N, base::dimension::U2, base::dimension::U1, <base::default_allocator::DefaultAllocator as base::allocator::Allocator<N, base::dimension::U2>>::Buffer> {base::construction::<impl base::matrix::Matrix<N, base::dimension::U2, base::dimension::U1, <base::default_allocator::DefaultAllocator as base::allocator::Allocator<N, base::dimension::U2>>::Buffer>><N>::new}: NoSolution
  --> src/base/swizzle.rs:14:30
   |
14 |                       $Result::new($(self[$i]),*)
   |                                ^^^
...
21 | / impl_swizzle!(
22 | |     where U0: xx() -> Vector2[0, 0];
23 | |     where U1: xy() -> Vector2[0, 1];
24 | |     where U2: xz() -> Vector2[0, 2];
...  |
66 | |     where U2: zzz() -> Vector3[2, 2, 2]
67 | | );
   | |__- in this macro invocation

error: internal compiler error: broken MIR in DefId(0/0:8135 ~ nalgebra[ff9d]::base[0]::swizzle[0]::{{impl}}[1]::xy[0]) (const base::construction::<impl base::matrix::Matrix<N, base::dimension::U2, base::dimension::U1, <base::default_allocator::DefaultAllocator as base::allocator::Allocator<N, base::dimension::U2>>::Buffer>>::new): bad constant user type FnDef(DefId(0/0:8339 ~ nalgebra[ff9d]::base[0]::construction[0]::{{impl}}[47]::new[0]), Canonical { variables: [CanonicalVarInfo { kind: Ty(General) }, CanonicalVarInfo { kind: Ty(General) }, CanonicalVarInfo { kind: Ty(General) }], value: UserSubsts { substs: [_], user_self_ty: Some(UserSelfTy { impl_def_id: DefId(0/0:8338 ~ nalgebra[ff9d]::base[0]::construction[0]::{{impl}}[47]), self_ty: base::matrix::Matrix<_, base::dimension::U2, base::dimension::U1, base::matrix_array::MatrixArray<_, base::dimension::U2, base::dimension::U1>> }) } }) vs fn(N, N) -> base::matrix::Matrix<N, base::dimension::U2, base::dimension::U1, <base::default_allocator::DefaultAllocator as base::allocator::Allocator<N, base::dimension::U2>>::Buffer> {base::construction::<impl base::matrix::Matrix<N, base::dimension::U2, base::dimension::U1, <base::default_allocator::DefaultAllocator as base::allocator::Allocator<N, base::dimension::U2>>::Buffer>><N>::new}: NoSolution
  --> src/base/swizzle.rs:14:30
   |
14 |                       $Result::new($(self[$i]),*)
   |                                ^^^
...
21 | / impl_swizzle!(
22 | |     where U0: xx() -> Vector2[0, 0];
23 | |     where U1: xy() -> Vector2[0, 1];
24 | |     where U2: xz() -> Vector2[0, 2];
...  |
66 | |     where U2: zzz() -> Vector3[2, 2, 2]
67 | | );
   | |__- in this macro invocation

# --- snip ---

This error is coming up when checking, building and when building for --release.

I'm running this on Ubuntu 18.04, here's some more information:

$ rustc -Vv
rustc 1.31.0-nightly (1dceaddfb 2018-10-17)
binary: rustc
commit-hash: 1dceaddfbe163e2d916c904b98923342730ba970
commit-date: 2018-10-17
host: x86_64-unknown-linux-gnu
release: 1.31.0-nightly
LLVM version: 8.0

$ cargo -Vv
cargo 1.31.0-nightly (5dbac9888 2018-10-08)
release: 1.31.0
commit-hash: 5dbac98885199bbd7c0f189d7405b5523434d1e3
commit-date: 2018-10-08

$ uname -srmo
Linux 4.15.0-33-generic x86_64 GNU/Linux

To reproduce this, ensure you've the same Rust nightly version installed as mentioned above. Then clone the nalgebra repository and run cargo check (faster than compiling). The error should come up when checking nalgebra starts.

[matthewjasper]

cc @nikomatsakis related to type annotation PRs?

[vadixidav]

This also happens on Windows for me. Same errors.

[nikomatsakis]

Could be.

[nikomatsakis]

I think this may be fixed with #55152 -- at least I did not observe it. I'll do a better test though

[nikomatsakis]

Up, I am wrong, I see it.

[nikomatsakis]

This is probably an RC2 blocker :(

[nikomatsakis]

I'm going to try and take a look

[nikomatsakis]

Hmm actually it seems like my branch does fix this.. or at least I am not reproducing now that I did a proper build (all the way to stage2, without --keep-stage or any such nonsense). Checking again. =)

[nikomatsakis]

Oh, geez, I am seeing these errors, but they seem to somehow interact with incremental in a nasty way that makes them go away on the second run! No wonder I keep getting confused.

[nikomatsakis]

I have a fix. I will tack it on to #55152

[nikomatsakis]

I just need a small test case now :P

[nikomatsakis]

Got one, pushed fix to #55152

[ElusiveMori]

@nikomatsakis Pardon me, but do you reckon there's an ETA on when the PR might land in nightly?
I tried rolling back to before this issue was introduced, but RLS refused to work with it for some reason (can't install it with rustup), meaning that I am blocked now until this issue is resolved (I imagine many other nalgebra users as well).

[matthewjasper]

It will be in the next nightly I think

[timvisee]

I can confirm that this is fixed in the latest nightly. Thanks a bunch, that was a quick fix!