This impl somehow now breaks Rust -- see the failed tests -- and causes a recursion errror - for an expression that has typef32 +f32 which is quite strange/scary(!)

   --> tests/oper.rs:159:48    |159 |         .fold(f32::zero(), |acc, (&x, &y)| acc + x * y)    |                                                ^    |    = help: consider adding a `#![recursion_limit="256"]` attribute to your crate (`oper`)    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`    = note: required because of the requirements on the impl of `Add<&ndarray::ArrayBase<_, _>>` for `f32`

Unsure if this is a Rust bug - for example that the impl is accepted(?), but I think this impl is too general and has infinite descent.

Given the question iff32 implementsAdd<&ArrayBase<S, D>> look for other impl that hasf32: Add<A> whereS: Data<Elem=A> which looks recursive, is that it?

It looks like a compiler bug to me. As you point out, the expression involves onlyf32, but for some reason, the error message indicates that one of the arguments is an array. It's also interesting that on my machine with Rust 1.48.0, the error message is slightly different, saying "impl ofAdd<ndarray::ArrayBase<_, _>> forf32" instead of the error message in your comment "impl ofAdd<&ndarray::ArrayBase<_, _>> forf32". (Note the&.)

The function fails to compile (with the same error message) even after adding type annotations:

fnreference_dot<'a,V1,V2>(a:V1,b:V2) ->f32whereV1:AsArray<'a,f32>,V2:AsArray<'a,f32>,{let a:ArrayView1<'a,f32> = a.into();let b:ArrayView1<'a,f32> = b.into();    a.iter().zip(b.iter()).fold(f32::zero(), |acc:f32,(&x,&y):(&f32,&f32)| acc + x* y)}

but if I remove the+ x * y, it compiles successfully:

fnreference_dot<'a,V1,V2>(a:V1,b:V2) ->f32whereV1:AsArray<'a,f32>,V2:AsArray<'a,f32>,{let a:ArrayView1<'a,f32> = a.into();let b:ArrayView1<'a,f32> = b.into();    a.iter().zip(b.iter()).fold(f32::zero(), |acc:f32,(&x,&y):(&f32,&f32)| acc)}

I don't see any reason other than a compiler bug for the first function to fail to compile when the second one compiles without errors, since the type annotations confirm that the closure is operating only onf32 values.

This also compiles successfully:

fnreference_dot2<'a>(a:ArrayView1<'a,f32>,b:ArrayView1<'a,f32>) ->f32{    a.iter().zip(b.iter()).fold(f32::zero(), |acc:f32,(&x,&y):(&f32,&f32)| acc + x* y)}

so the bug involves the.into() calls in some way. It's surprising that adding explicit type annotations for the results of the.into() calls, as in the first example, doesn't work around the bug.

Fwiw, I don't thinkimpl<'a, A, S, D, B> $trt<&'a ArrayBase<S, D>> for $scalar is infinitely recursive, since AFAIK it's not possible to have an array of (arrays of (arrays of (arrays of ... [infinite depth]))). The innermost array type can only have an element type that's not an array. You're right that there is recursion if you're dealing with arrays of arrays, but that's the correct behavior, and the recursion is not infinite.

For the particular function we're looking at, the impl doesn't apply, and I don't think the compiler should be trying to apply it. (I think it should only apply the impl if it knows the RHS has some type&ArrayBase<?S, ?D>, where?S and?D are inference variables.)

Interesting, the test runners for cross_test, stable, mips vs i686 disagree with each other about the error too, in the same way, even if they both use Rust 1.48

I reported the issue (with a simplified example) atrust-lang/rust#80542.