Codecov Report

Patch coverage has no change and project coverage change: +0.03% 🎉

Comparison is base (914d1d6) 84.84% compared to head (cfa9535) 84.87%.
Report is 2 commits behind head on series/0.14.x.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.

@@                Coverage Diff                @@
##           series/0.14.x    #2187      +/-   ##
=================================================
+ Coverage          84.84%   84.87%   +0.03%     
=================================================
  Files                 76       76              
  Lines               2731     2731              
  Branches             371      374       +3     
=================================================
+ Hits                2317     2318       +1     
+ Misses               414      413       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@MartinHH, Looks like even if we get the compiler to generate these codecs at compile time, we will have a runtime issue with trees of sufficient size blowing up the stack. I pushed some test changes to limit the test size so we can address this later, but on my machine i could upwards of 10,000 depth fine... in CI that number is much smaller, making me somewhat concerned about the real world limits.

As it stands right now, users will be forced to do something other than derivation, which i think is better than merging this right now and possibly getting a stack overflow at runtime.

If we still wanted to get this in, we need to change the way the encoder/decoder works to be more like Defer/Fix #2123 or some other trick to trampoline on the stack rather than blow it up.

As it stands right now, users will be forced to do something other than derivation, which i think is better than merging this right now and possibly getting a stack overflow at runtime.

Not trying to talk you into merging this (I really don't mind as I wasn't planning to use this), but it might be worth pointing out that the following already compiles (resulting in a similarly unsafe codec):

sealed trait Tree derives Codec.AsObject
case class Branch(l: Tree, r: Tree) extends Tree
case object Leaf extends Tree

This as well:

sealed trait Tree
case class Branch(l: Tree, r: Tree) extends Tree
case object Leaf extends Tree
given Codec[Tree] = Codec.AsObject.derived[Tree]

On the one hand, I cannot wait for this aspect of circe in Scala 3 to be improved (and I am saddened by the lack of activity for almost 2 months), but I think this is the right place to point out a weird peculiarity which may be worth considering before merging anything.

@MartinHH mentioned, that derivation for his Tree structure compiles. While Martin is right, that is the following compiles:

import io.circe.Codec

sealed trait Tree
case class Branch(l: Tree, r: Tree) extends Tree
case object Leaf extends Tree
given Codec[Tree] = Codec.AsObject.derived[Tree]

the following doesn't:

import io.circe.Codec

sealed trait Tree
case class Branch(l: Tree, r: Tree) extends Tree
case object Leaf extends Tree
case class TreeWrapper(tree: Tree)
given Codec[TreeWrapper] = Codec.AsObject.derived[TreeWrapper]

The latter piece of code fails to compile with the infamous Maximal number of successive inlines (32) exceeded error. And the only thing that changed was moving from deriving for a recursive type to deriving for a type which contained a recursive type.