given instance is declared as erased, but is in fact used

Compiler version

3.0.1

Minimized code

import scala.deriving.Mirror
import scala.compiletime._

trait Schema[T] {
  def build: T
}

object Schema extends SchemaDerivation {
  implicit lazy val int: Schema[Int]   = ???
  implicit def option[A](implicit ev: Schema[A]): Schema[Option[A]] = ???
}

trait SchemaDerivation {
  inline def recurse[A <: Tuple]: List[Schema[Any]] =
    inline erasedValue[A] match {
      case _: (t *: ts) =>
        val builder = summonInline[Schema[t]].asInstanceOf[Schema[Any]]
        builder :: recurse[ts]
      case _: EmptyTuple => Nil
    }

  inline def derived[A]: Schema[A] =
    inline summonInline[Mirror.Of[A]] match {
      case m: Mirror.SumOf[A] =>
        lazy val subTypes = recurse[m.MirroredElemTypes]
        new Schema[A] {
          def build: A = ???
        }

      case m: Mirror.ProductOf[A] =>
        lazy val fields = recurse[m.MirroredElemTypes]
        new Schema[A] {
          def build: A = ???
        }
    }

  inline given gen[A]: Schema[A] = derived
}

case class H(i: Int)
case class G(h: H)
case class F(g: G)
case class E(f: Option[F])
case class D(e: E)
case class C(d: D)
case class B(c: C)
case class A(a: Option[A], b: B)

object TestApp {
  @main def test = {
    implicit lazy val typeSchema: Schema[A] = Schema.gen
  }
}

Output

given instance gen is declared as erased, but is in fact used
method recurse is declared as erased, but is in fact used

Expectation

I got this error while upgrading caliban from 3.0.0 to 3.0.1 on some code that was previously compiling. It seems that it fails to derive a typeclass instance in the presence of recursion and nesting. If I reduce the nesting, it works. I managed to reproduce it with the smaller example above, but this code fails with 3.0.0 with a different error. Any idea what’s going on?

[adamw]

We’ve hit this problem in tapir (https://github.com/softwaremill/tapir/issues/1731), and minimized a bit in magnolia (https://github.com/softwaremill/magnolia/issues/374). While bumping the max-inline does solve the problem, I think it’s not really resolved - we either have to come up with a better solution in magnolia (suggestions welcome 😃 - one idea we have is to replace depending on Mirrors with macros, but if at all, this might only reduce the inlining height, not eliminate it completely) or maybe bump the limit in Scala?

The case classes involved aren’t that complicated, so I suspect this might surface once and again when using typeclass derivation (esp using Magnolia) in real-world scenarios, which get much more complex.

Finally, the error is quite misleading. Maybe it would make sense to open another issue to make this more actionable (sth like “Max-inline limit reach. Increase using max-inlines to continue”? Would that be technically possible to detect?

[dwijnand]

Also a bit annoying for build.sbt that we can’t use -Xmax-inlines:33 or -Xmax-inlines=33

Coming in 3.1.0: https://github.com/lampepfl/dotty/pull/13267