Incrementally compiled code that iterates over Mirror's MirroredElemTypes
in a macro sometimes dealiases an opaque
type to its underlying type
#21430
Labels
Compiler version
3.3.3
Minimized code
The best I could do is a branch on a public project: https://github.com/arainko/ducktape/tree/issue-197-repro
Steps to reproduce:
issue-197-repro
repro.scala
(the code should compile if you clean-compiled, it also outputs a compiletime message of the types taken from the destination'sMirror.MirroredElemTypes
which reads:Field types: String, Ident
)object demo
Configuration is not valid since the provided type (io.github.arainko.ducktape.scoped.Ident) is not a subtype of java.lang.String @ To.id
- it gives us a hint towards what went wrong.The aforementioned compiletime message changes to
Field types: String, String
(Ident
is an opaque type overString
) - we can deduce thatIdent
was dealiased toString
despite the code being outside a scope where this identity is visible.What's worth noting is that I wasn't able to reproduce the correct behavior of the code if I copy-pasted the offending file to a separate project with
ducktape
pulled in as a dep. It always fails no matter what I do (on 3.3.3 and 3.5.0).The code that does the tuple decomposition doesn't do anything that I'd deem 'dangerous' in relation to opaque types (it doesn't
.dealias
,.widen
etc) - it only summons theMirror
of a given type and pattern matches over it (here )This issue was first reported here: arainko/ducktape#197
Expectation
scoped.Ident
is not dealiased to its underlying type.The text was updated successfully, but these errors were encountered: