assertion failed: class Array while introspecting Array[Byte] in a macro #21916
Comments
pshirshov
added
itype:bug
stat:needs triage
Gedochao
added
itype:crash
stat:needs minimization
|
Scala CLI repro: //> using dep dev.zio::izumi-reflect:2.3.10
@main def main() = izumi.reflect.Tag.tagFromTagMacro[Array[Byte]]We'll need this minimized without the |
|
I don't think I can do it. We have a stable repro and a reasonable stacktrace. Although this bug seem to be happening lot later than the macro phase and i-r macros are ones of the most complicated ones which ever existed for Scala. Moreover, from what I can remember, there were similarly looking bugs which were affected by mere syntactic rearrangements. So, for me the effort required for further minimization looks insurmountable. |
|
Minimisation: import scala.quoted._
object Macro:
inline def test() = ${testImpl}
def testImpl(using Quotes): Expr[Any] = {
import quotes.reflect._
val tpe = TypeRepr.of[Array[Byte]] match
case AppliedType(tycons, _) => tycons
Literal(ClassOfConstant(tpe)).asExpr
}Main.scala: @main def main() = Macro.test()We need to add -Xcheck-macros check for parameters of classOf[] (and perhaps other type parameter lists too) - though for classOf this probably only matters for Arrays As a side note, for anyone struggling with similar issues, calling macro methods with |
…#22033) Closes #21916 I tried to supply the ClassOfConstant with multiple other broken Types, but I was unable to break it beyond the linked issue, so I ended up adding the check for only that one case. This makes sense - the backend (and thus erasure) needs to know if the Array type parameter is a primitive type, but in other cases the erasure phase needs to know only the class, without the type parameters. It's impossible to call classOf through the quoted code (`'{classOf[t]}` with a boundless t will error out), so we don't need that additional check there. There does appear to be an issue with being able to set `'{List[Array]}` resulting in a crash, but that is beyond the scope of this fix - I will prepare a separate issue for that (edit: reported [here](#22034)).
|
@jchyb : there is an open bounty for this: zio/izumi-reflect#474 , you may claim it if you wish. You can't open an empty P/R, but a single-line test would suffice. |
|
@pshirshov, I'd rather not, especially that we only replaced the crash with an error, rather than doing something that will completely fix the issue with izumi-reflect just by bumping the compiler version (we can't really do that). The problem still remains in izumi-reflect, the difference is now you should just get a more actionable compiletime error (instead of a confusing crash). The problem is that currently izumi-reflect can generate something like: For now, the added check in the compiler only throws errors for Arrays, but, preferably, things like |
Indeed. I didn't understand your initial message in the issue thread – assuming the type parameters were somehow lost by the compiler, not in the code itself – since we weren't intentionally stripping them ourselves. Instead they were lost because we were directly using the output of
I think we can't do that, because we generate Tags for unapplied HKTs as well - which don't have applied type parameters and recovering which might be quite tricky depending on their bounds. Note that generating classOfs for unapplied types works on Scala 2 as well, so there's some continuity in this behavior. With the above fix, type parameters will now be retained for proper types, but there will be still be unapplied classOfs for HKT tags. |
I had a feeling like we already reported this, but can't find anything.
The compiler fails while
izumi-reflectintrospectsArray[Byte]with an obscure stacktrace:Here is the repro: https://scastie.scala-lang.org/3P7O5JyuSaaEzHQ9WUGoGQ
It fails on any Scala 3 version.
It looks like it's a compiler bug as it only happens with Arrays. If we improperly use the API, the diagnostic message should be improved, at the moment it's completely misleading.
Once this is resolved, zio/izumi-reflect#474 might be closed and the bounty should remain unclaimed.
The text was updated successfully, but these errors were encountered: