You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a very simple macro here that makes use of ClassSymbol.knownDirectSubclasses
The macro is invoked in the test (EnumerateSpec.scala). It works as expected when you pass it the type of trait Foo, which is defined in src/main. But when you pass it the type of trait Goo, which is defined in src/test, it cannot find any of the trait's subclasses. (ClassSymbol.knownDirectSubclasses returns an empty Set, as you can see from the println output.)
The weird thing is, if you then make an edit to src/main/scala/enumerate/package.scala, triggering recompilation, then the macro starts working as expected and the tests pass. So I'm guessing this is somehow related to compilation order.
At first I thought it might be a thread-safety issue similar to #6240, but as far as I can tell the Symbol has already been initialized. Manually calling initialize, info, etc. before knownDirectSubclasses did not fix the problem.
The text was updated successfully, but these errors were encountered:
@xeno-by said:
This is a duplicate of #7046. Thank you very much for taking time to provide such a detailed report - I've linked it to the original issue!
I have a very simple macro here that makes use of
ClassSymbol.knownDirectSubclasses
The macro is invoked in the test (EnumerateSpec.scala). It works as expected when you pass it the type of trait
Foo
, which is defined insrc/main
. But when you pass it the type of traitGoo
, which is defined insrc/test
, it cannot find any of the trait's subclasses. (ClassSymbol.knownDirectSubclasses
returns an empty Set, as you can see from theprintln
output.)If you checkout the
bugreport
branch of https://github.com/cb372/enumerate and runsbt test
you can see for yourself.The weird thing is, if you then make an edit to
src/main/scala/enumerate/package.scala
, triggering recompilation, then the macro starts working as expected and the tests pass. So I'm guessing this is somehow related to compilation order.At first I thought it might be a thread-safety issue similar to #6240, but as far as I can tell the Symbol has already been initialized. Manually calling
initialize
,info
, etc. beforeknownDirectSubclasses
did not fix the problem.The text was updated successfully, but these errors were encountered: