'@sp' causing stack overflow on implicitly[Numeric[Int/Long/Double/Float]].toRational()

[erikerlandson]

Happens for all the native typesInt, Long, Double, Float. Doesn't seem to happen for non-native types like BigInt.

[eje@localhost spire]$ xsbt coreJVM/console
Welcome to Scala 2.12.0 (OpenJDK 64-Bit Server VM, Java 1.8.0_111).
Type in expressions for evaluation. Or try :help.

scala> import spire.implicits._; import spire.math._
import spire.implicits._
import spire.math._

scala> implicitly[Numeric[Int]].toRational(1)
java.lang.StackOverflowError
  at spire.std.IntIsReal.toBigInt(int.scala:68)
  at spire.std.IntIsReal.toBigInt$(int.scala:68)
  at spire.math.IntIsNumeric.toBigInt$mcI$sp(Numeric.scala:97)
  at spire.std.IntIsReal.toBigInt(int.scala:68)
  at spire.std.IntIsReal.toBigInt$(int.scala:68)
  at spire.math.IntIsNumeric.toBigInt$mcI$sp(Numeric.scala:97) ....

[erikerlandson]

Looks like it it is some kind of interaction with @sp specializations, which would explain why it's happening with Int/Long/Float/Double.

[erikerlandson]

Wondering how important @sp really is in this hierarchy. Isn't specialization already being achieved with the type-specific implicits, like IntIsNumeric, DoubleIsNumeric, etc?

[erikerlandson]

Confirmed that if I remove @sp from Numeric[A] and some related traits, it fixes the problem.