Recursion limit reached when evaluating trait bounds for trait impl on reference type.

[Zistack]

I tried this code:

use std::ops::Mul;

trait Muls <Rhs>:
	Mul <Rhs, Output = <Self as Muls <Rhs>>::Output>
	+ for <'a> Mul <&'a Rhs, Output = <Self as Muls <Rhs>>::Output>
{
	type Output;
}

impl <T, R, O> Muls <R> for T
where
	T: Mul <R, Output = O>,
	T: for <'a> Mul <&'a R, Output = O>
{
	type Output = O;
}

trait ScalarMulCore
{
	type Scalar;

	fn scalar_mul (&self, rhs: &Self::Scalar) -> Self;

	fn scalar_mul_in_place (&mut self, rhs: &Self::Scalar);
}

struct Wrap <T> {x: T}

impl <T> ScalarMulCore for Wrap <T>
where
	T: Muls <T, Output = T>,
	for <'a> &'a T: Muls <T, Output = T>
{
	type Scalar = T;

	fn scalar_mul (&self, rhs: &Self::Scalar) -> Self
	{
		Self {x: (&self . x) * rhs}
	}

	fn scalar_mul_in_place (&mut self, rhs: &Self::Scalar)
	{
		self . x = (&self . x) * rhs;
	}
}

impl <T> Mul <<Wrap <T> as ScalarMulCore>::Scalar> for Wrap <T>
where Wrap <T>: ScalarMulCore
{
	type Output = Wrap <T>;

	fn mul (mut self, rhs: <Wrap <T> as ScalarMulCore>::Scalar) -> Self::Output
	{
		self . x = (&self . x) * rhs;
		self
	}
}

impl <T> Mul <<Wrap <T> as ScalarMulCore>::Scalar> for &Wrap <T>
where Wrap <T>: ScalarMulCore
{
	type Output = Wrap <T>;

	fn mul (self, rhs: <Wrap <T> as ScalarMulCore>::Scalar) -> Self::Output
	{
		Wrap::<T> {x: (&self . x) * rhs}
	}
}

fn main ()
{
}

I expected to see this happen: The code compiles.

Instead, this happened: The code does not compile.

Meta

rustc --version --verbose:

rustc 1.69.0-nightly (ef934d9b6 2023-02-08)
binary: rustc
commit-hash: ef934d9b632b8ac00276558824664c104b92b5f0
commit-date: 2023-02-08
host: x86_64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7

Backtrace

   Compiling mwe v0.1.0 (/home/zistack/Projects/mwe)
error[E0275]: overflow evaluating the requirement `for<'a> &'a Simd<_, _>: Mul<Simd<_, _>>`
  --> src/main.rs:47:56
   |
47 | impl <T> Mul <<Wrap <T> as ScalarMulCore>::Scalar> for Wrap <T>
   |                                                        ^^^^^^^^
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`mwe`)
note: required for `&'a Simd<_, _>` to implement `for<'a> Muls<Simd<_, _>>`
  --> src/main.rs:10:16
   |
10 | impl <T, R, O> Muls <R> for T
   |                ^^^^^^^^     ^
11 | where
12 |     T: Mul <R, Output = O>,
   |                ---------- unsatisfied trait bound introduced here
note: required for `Wrap<Simd<_, _>>` to implement `ScalarMulCore`
  --> src/main.rs:29:10
   |
29 | impl <T> ScalarMulCore for Wrap <T>
   |          ^^^^^^^^^^^^^     ^^^^^^^^
...
32 |     for <'a> &'a T: Muls <T, Output = T>
   |                              ---------- unsatisfied trait bound introduced here
   = note: 62 redundant requirements hidden
   = note: required for `Wrap<_>` to implement `ScalarMulCore`

For more information about this error, try `rustc --explain E0275`.
error: could not compile `mwe` due to previous error

Commenting out the second implementation of `Mul` lets the code compile. So does manually inlining the `ScalarMulCore` trait definition into the `Mul` implementations. These facts, along with the fact that `rustc` is complaining about a type which I never asked for (and which should work anyways) make me think that this is a compiler bug. I would appreciate confirmation on this from a rust expert, though.

There is a chance that this issue is related to #107837, as the nature of the failure looks very similar to me. Other versions of this that I've tried buried the Muls traits in another layer of traits (MulsToSelf, MulsToOther), which changes the error message to something complaining about Wrap <Wrap <T>> and such.

[Zistack]

It looks like this has been an issue for quite some time now. Going through the history a little more thoroughly reveals many threads which are likely related. Here's just a few.

#96634
#90212
#106512
#37748

And those all reference further issues.

This thread even has the Simd type showing up in the error message.

This is a major problem for my application, and will require significant work to work around. Is there a tracking issue for this bug?