Change:
<ins> // Regression test for #66768. // check-pass #![allow(dead_code)] //-^ "dead code" is needed to reproduce the issue. use std::marker::PhantomData; use std::ops::{Add, Mul}; fn problematic_function<Space>(material_surface_element: Edge2dElement) where DefaultAllocator: FiniteElementAllocator<DimU1, Space>, { let _: Point2<f64> = material_surface_element.map_reference_coords().into(); } impl<T> ArrayLength<T> for UTerm { type ArrayType = (); } impl<T, N: ArrayLength<T>> ArrayLength<T> for UInt<N, B0> { type ArrayType = GenericArrayImplEven<T, N>; } impl<T, N: ArrayLength<T>> ArrayLength<T> for UInt<N, B1> { type ArrayType = GenericArrayImplOdd<T, N>; } impl<U> Add<U> for UTerm { type Output = U; fn add(self, _: U) -> Self::Output { unimplemented!() } } impl<Ul, Ur> Add<UInt<Ur, B1>> for UInt<Ul, B0> where Ul: Add<Ur>, { type Output = UInt<Sum<Ul, Ur>, B1>; fn add(self, _: UInt<Ur, B1>) -> Self::Output { unimplemented!() } } impl<U> Mul<U> for UTerm { type Output = UTerm; fn mul(self, _: U) -> Self { unimplemented!() } } impl<Ul, B, Ur> Mul<UInt<Ur, B>> for UInt<Ul, B0> where Ul: Mul<UInt<Ur, B>>, { type Output = UInt<Prod<Ul, UInt<Ur, B>>, B0>; fn mul(self, _: UInt<Ur, B>) -> Self::Output { unimplemented!() } } impl<Ul, B, Ur> Mul<UInt<Ur, B>> for UInt<Ul, B1> where Ul: Mul<UInt<Ur, B>>, UInt<Prod<Ul, UInt<Ur, B>>, B0>: Add<UInt<Ur, B>>, { type Output = Sum<UInt<Prod<Ul, UInt<Ur, B>>, B0>, UInt<Ur, B>>; fn mul(self, _: UInt<Ur, B>) -> Self::Output { unimplemented!() } } impl<N, R, C> Allocator<N, R, C> for DefaultAllocator where R: DimName, C: DimName, R::Value: Mul<C::Value>, Prod<R::Value, C::Value>: ArrayLength<N>, { type Buffer = ArrayStorage<N, R, C>; fn allocate_uninitialized(_: R, _: C) -> Self::Buffer { unimplemented!() } fn allocate_from_iterator<I>(_: R, _: C, _: I) -> Self::Buffer { unimplemented!() } } impl<N, C> Allocator<N, Dynamic, C> for DefaultAllocator { type Buffer = VecStorage<N, Dynamic, C>; fn allocate_uninitialized(_: Dynamic, _: C) -> Self::Buffer { unimplemented!() } fn allocate_from_iterator<I>(_: Dynamic, _: C, _: I) -> Self::Buffer { unimplemented!() } } impl DimName for DimU1 { type Value = U1; fn name() -> Self { unimplemented!() } } impl DimName for DimU2 { type Value = U2; fn name() -> Self { unimplemented!() } } impl<N, D> From<VectorN<N, D>> for Point<N, D> where DefaultAllocator: Allocator<N, D>, { fn from(_: VectorN<N, D>) -> Self { unimplemented!() } } impl<GeometryDim, NodalDim> FiniteElementAllocator<GeometryDim, NodalDim> for DefaultAllocator where DefaultAllocator: Allocator<f64, GeometryDim> + Allocator<f64, NodalDim> { } impl ReferenceFiniteElement for Edge2dElement { type NodalDim = DimU1; } impl FiniteElement<DimU2> for Edge2dElement { fn map_reference_coords(&self) -> Vector2<f64> { unimplemented!() } } type Owned<N, R, C> = <DefaultAllocator as Allocator<N, R, C>>::Buffer; type MatrixMN<N, R, C> = Matrix<N, R, C, Owned<N, R, C>>; type VectorN<N, D> = MatrixMN<N, D, DimU1>; type Vector2<N> = VectorN<N, DimU2>; type Point2<N> = Point<N, DimU2>; type U1 = UInt<UTerm, B1>; type U2 = UInt<UInt<UTerm, B1>, B0>; type Sum<A, B> = <A as Add<B>>::Output; type Prod<A, B> = <A as Mul<B>>::Output; struct GenericArray<T, U: ArrayLength<T>> { _data: U::ArrayType, } struct GenericArrayImplEven<T, U> { _parent2: U, _marker: T, } struct GenericArrayImplOdd<T, U> { _parent2: U, _data: T, } struct B0; struct B1; struct UTerm; struct UInt<U, B> { _marker: PhantomData<(U, B)>, } struct DefaultAllocator; struct Dynamic; struct DimU1; struct DimU2; struct Matrix<N, R, C, S> { _data: S, _phantoms: PhantomData<(N, R, C)>, } struct ArrayStorage<N, R, C> where R: DimName, C: DimName, R::Value: Mul<C::Value>, Prod<R::Value, C::Value>: ArrayLength<N>, { _data: GenericArray<N, Prod<R::Value, C::Value>>, } struct VecStorage<N, R, C> { _data: N, _nrows: R, _ncols: C, } struct Point<N, D> where DefaultAllocator: Allocator<N, D>, { _coords: VectorN<N, D>, } struct Edge2dElement; trait ArrayLength<T> { type ArrayType; } trait Allocator<Scalar, R, C = DimU1> { type Buffer; fn allocate_uninitialized(nrows: R, ncols: C) -> Self::Buffer; fn allocate_from_iterator<I>(nrows: R, ncols: C, iter: I) -> Self::Buffer; } trait DimName { type Value; fn name() -> Self; } trait FiniteElementAllocator<GeometryDim, NodalDim>: Allocator<f64, GeometryDim> + Allocator<f64, NodalDim> { } trait ReferenceFiniteElement { type NodalDim; } trait FiniteElement<GeometryDim>: ReferenceFiniteElement where DefaultAllocator: FiniteElementAllocator<GeometryDim, Self::NodalDim>, { fn map_reference_coords(&self) -> VectorN<f64, GeometryDim>; } fn main() {} </ins>

Discussion:
(Please feel free to make the title more precise) This issue was first reported as part of , as it was first believed to be similar in nature. Please also see the discussion therein. However, it seems to be sufficiently different as to warrant its own issue. Here is an example I've created a relatively minimal testcase, and helped me minimize it further. The testcase can be found here: . The current file is set to , but the bug manifests for a number of different version of (but not all!), as well as , and before minification it was also present on . The conditions triggering the ICE seem to be very brittle: Changing features of dependencies or removing unused dependencies might make the ICE vanish. See also observations in the aforementioned issue .
Backtrace:
modify labels: E-needs-mcve E-needs-bisection
The types in the ICE message are: That does look like a missing normalization, but those are not usually so hard to reproduce.
What about the warning beforehand (sorry, I overseen it): maybe an incremental problem which might be the reason for the "hard to reproduce" problem?
I turned off incremental compilation for all my tests. The bug is completely reproducible without incremental compilation. EDIT: See clarification below.
sorry, my initial statement was unclear and might be misunderstood. What I meant is that incremental compilation has no influence on the "hard to reproduce" property of the bug. I explicitly turned off incremental compilation for all my debugging, and the weird behavior with e.g. removing dependencies or features still persisted.
Especially bizarre is when you substitute "default" for "std" when default only implies "std" in the for . Non-default doesn't ICE despite not influencing the generated code at all AFAICT.
This issue reminds of which has been fixed by . Bisection shows regression somewhere between ... but I can't find a commit that would make sense... :/
Probably bisection is going to be difficult since the bug is so hard to reliably reproduce. It would help to reduce it further (removing the dependency) and figuring out why the issue only happens sometimes (and what changes when it doesn't happen).

Reduced example gives "broken MIR" error on current stable & nightly:
BTW I made extensive use of C-reduce and rust-reduce to get here, which I notice didn't mention in his blog ;)
Did this ever work, by the way? This is tagged "needs-bisect", but that won't help if this isn't a regression... (or maybe the bisection is just to identify whether or not this is a regression?)
shots fired! (I admit I didn't mention them there, in part because I have little experience using them. I should try using them, and maybe try adding my techniques to rust-reduce.)
, there was discussion prior to determining these are separate issues.
the discussion you linked talks about the problem going away between nightlies for 2019-11-15 and 2019-11-16. to my eye, that is not an example of this code having worked in the past, but rather makes it an example of an intermittent failure... (I know at that point it may be in the eye of the beholder...) more specifically, when running atop 's [reduction][], I continue to see an ICE as far back as nightly-2019-01-01. (I'll pull up some older nightlies in a bit... I had cleaned out my directory a while back to free up space on my laptop and decided that I surely wouldn't need anything from 2018 or earlier...) [reduction]:
The reduced example gives a error since . <details<summary<strongICE on nightly-2017-08-31</strong</summary</detailsBefore that it compiles with nothing but unused-warnings. This should be an exhaustive list of (merge) commits for that nightly: Edit: Going a bit further back, before this code again didn’t compile, with no ICE, but an error message about impls of . <details<summary<strongerror on nightly-2017-07-07</strong</summary</detail
I can't get the MVCE to ice on the latest nightly. Can anyone confirm?
using 's . (Still fails on stable) Status for your project?
I cannot reproduce the ICE with or since 1.44.0, it compiles fine instead. Note that we have to tweak the dependencies of like: Otherwise, cargo cannot resolve the deps.

I'm going to mark this as since we could say it's now fixed, even though we didn't bisect. (And I think can be the MCVE of this issue since it seems they have the same cause.)
that’s not too much effort, here we go: searched nightlies: from nightly-2020-02-01 to nightly-2020-08-05 regressed nightly: nightly-2020-04-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Thanks So, this part fixes the issue, I believe: