runtime/compile time reflection doesn't see all knownDirectSubclasses

[scabug]

Unlike, say, annotations or flags, knownDirectSubclasses doesn't get auto-populated and requires a symbol to be pre-initialized to work correctly.

import scala.reflect.runtime.universe._
import scala.reflect.runtime.{currentMirror => cm}

sealed class C
class D extends C
class E extends C

object Test extends App {
  val c = cm.staticClass("C")
  println(c.knownDirectSubclasses)
  c.typeSignature
  println(c.knownDirectSubclasses)
}

19:43 ~/Projects/Kepler_7046/sandbox (ticket/7046)$ scalac Test.scala && scala Test
Set()
Set(class D, class E)

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7046?orig=1
Reporter: @xeno-by
Affected Versions: 2.10.0, 2.11.0
Other Milestones: 2.12.1

[scabug]

@xeno-by said:
Probably should a very easy fix. Will try to get it once we're discussing synchronization.

[scabug]

@xeno-by said:
scala/scala#2039

[scabug]

@xeno-by said:
Fixed in scala/scala@2403d1d

[scabug]

@adriaanm said:
Actually, this only works when you query knownDirectSubclasses after those trees have been typed, so macros that occur before the class C in your example has been type checked won't see its subclasses.

[scabug]

@JamesIry said:
2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.

[scabug]

@retronym said:
Test case for compile time reflection in #7588

[scabug]

Valentin Churavy (wallnuss) said (edited on Dec 10, 2013 6:46:40 AM UTC):
I still run into this on 2.10.3 and the work around with calling c.typeSignature before c.knownDirectSubclasses doesn't work for the reason Adriaan noticed. Forcing a recompile on only the parts which use the macro solve this error, but that is of course not really satisfactory.

[scabug]

@adriaanm said:
Sorry, this is not something we can fix due the way the typechecker is implemented. The "fix" would be to remove this method from the reflection API.

[scabug]

Valentin Churavy (wallnuss) said:
Would it be possible to reschedule the classes where the macro is used for compilation after the TypeCheck has occurred?

[scabug]

@xeno-by said:
Discussion: https://groups.google.com/forum/#!topic/scala-internals/LRfKffsPxVA

[scabug]

@xeno-by said:
Actually, I think we can fix this for an important subset of macros: https://groups.google.com/forum/#!topic/scala-user/oJP9aqs88rM

[scabug]

@xeno-by said:
See another test case at #8776

[scabug]

@milessabin said:
@adriaanm can you elaborate on "this is not something we can fix due the way the typechecker is implemented" ... are there any specific obstacles you have in mind?

[scabug]

@Blaisorblade said:

1. Since this is a design issue, do scala.meta and/or Dotty change things here? I wonder if we need a label like redesign for such issues.
2. @milessabin the design issue is mentioned in the discussion links, in particular in https://groups.google.com/d/msg/scala-internals/LRfKffsPxVA/db_jmsa7FO4J:

knownDirectSubclasses relies on a full top-down pass having been completed before you call it.

Technically, we could provide a onTypecheckCompilationUnit that you could use, but this isn't currently planned for the macro api (well, I'll let Eugene comment on that, but I'm not aware of any plans here -- in any case, 2.11 is in ramp down)