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

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

@xeno-by said:
scala/scala#2039

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

@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.

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

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

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.

@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.

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

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

@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

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

@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?

@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)

@xeno-by said:
Scala.meta relies on the underlying platform typechecker, so it won't change anything here unless the implementation of scalac/dotc changes.

One way to fix this issue without changing the typechecker is to move macro expansion to after typer instead of during typer. We'll have to experiment with this, because there are some technical difficulties with implementing that (e.g. implicit inference not working well after typer, etc).

@milessabin said:
WIP PR here: scala/scala#5284

@cchantep said:
Could the following be used as workaround in some case (seems to work in my case as far as I can see).

val cls: ClassSymbol = sub.asClass

println(s"knownDirectSubclasses = ${cls.knownDirectSubclasses}")
// print "knownDirectSubclasses = Set()"

val subsub = cls.owner.typeSignature.decls.filter {
  case c: ClassSymbol =>
    cls != c && c.selfType.baseClasses.contains(cls)

  case _ => false
}

println(s"subsub = $subsub")
// print the actual sub classes

@milessabin said:
Fix backported to 2.11.8 is available here.

@adriaanm said:
scala/scala#5345

@adriaanm said:
To track future refinements, please open a new issue. Closing this one to mark our progress.