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

[ghostdogpr]

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?

[griggt]

FWIW, the example compiles for me on both 3.0.0 and 3.0.1 with -Xmax-inlines 33 (the default is 32)

[ghostdogpr]

FWIW, the example compiles for me on both 3.0.0 and 3.0.1 with -Xmax-inlines 33 (the default is 32)

Oh, I was not aware of this setting, I confirm it solves my initial problem 👍
Maybe the error message could be more explicit?

[joroKr21]

Is this a new option? The same code that compiled without it on Scala 3.0.0 now requires increasing this value on Scala 3.0.1: typelevel/kittens#376 Also a bit annoying for build.sbt that we can't use -Xmax-inlines:33 or -Xmax-inlines=33 😄

[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: #13267

[nicolasstucki]

It seems we are missing not inlining one of the calls to Schema.{gen, recurse}. This then fails with an error that mentions the erased nature of inline methods. This should wither inline during the inlining phase or fail with an error at that phase. It should not reach the erasure phase.

[ghostdogpr]

I had this error come up in a new place when I upgraded from 3.0.2 to 3.1.0 (similar derivation for very nested and recursive code). Increasing -Xmax-inlines didn't solve it this time, the compilation seemed to never end.

[nicolasstucki]

@ghostdogpr if -Xmax-inlines does not solve the issue this time, then it seems to be another issue. Could you open a new issue with the code that fails?

[ghostdogpr]

@nicolasstucki I have a hard time reproducing it in an isolated minimized way. Is it okay if I provide an entire repo?

[nicolasstucki]

Yes, we will mark it as needs-minimization. Just make sure to refer to a branch that will not change until the issue is fixed.

[ghostdogpr]

Opened #13785 👍

[adamw]

We've hit this problem in tapir (softwaremill/tapir#1731), and minimized a bit in magnolia (softwaremill/magnolia#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?