Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] method schemaForCaseClass is declared as erased, but is in fact used #1731

Open
Centaur opened this issue Jan 5, 2022 · 4 comments
Open
Assignees
Milestone

Comments

@Centaur
Copy link

Centaur commented Jan 5, 2022

Tapir version: 0.19.1+

Scala version: 3.1.0

Describe the bug

What is the problem?
mysterious compile errors

method isValueClass is declared as erased, but is in fact used
method isObject is declared as erased, but is in fact used
method schemaForCaseClass is declared as erased, but is in fact used
method anns is declared as erased, but is in fact used
method typeInfo is declared as erased, but is in fact used
method typeAnns is declared as erased, but is in fact used
method getParams is declared as erased, but is in fact used
method summon is declared as erased, but is in fact used

How to reproduce?

Maybe you can provide code to reproduce the problem?
https://scastie.scala-lang.org/Fy5fl0keRXWtP8i5bSCymA

Additional information
If reduce field numbe of case class StandardAreaInfo or TwinNode by 1,for example, comment country:String or city:String, or realSceneID:UUID or coverImage:Option[String] , the errors disappears

@pme123
Copy link
Contributor

pme123 commented Jan 10, 2022

I have the same Problem:
Tapir version: 0.18.3
Scala version: 3.1.0

To a certain point I could work around this problem with

    scalacOptions ++= Seq(
      "-Xmax-inlines",
      "50" // is declared as erased, but is in fact used
    )

Compiling gets really slow though.

I got this from here scala/scala3#13044

Maybe this is related.

@ahjohannessen
Copy link

ahjohannessen commented Jan 11, 2022

Same issue here, however I worked around it by using Schema.derived[T]

@kubinio123 kubinio123 self-assigned this Jan 14, 2022
@adamw
Copy link
Member

adamw commented Jan 24, 2022

See softwaremill/magnolia#374 - a bit minimized, but still mysterious

@adamw
Copy link
Member

adamw commented Jan 25, 2022

@Centaur your particular problem is solved by bumping max-inlines as @pme123 suggested (thanks!). Question remains, can we do something in magnolia about it, or maybe Scala should bump the inlining limit. These classes aren't that complicated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants