Imported From: https://issues.scala-lang.org/browse/SI-8548?orig=1
Reporter: @paulp
Affected Versions: 2.11.0

@paulp said:
The only way to obtain the deferred member is to call decls on all the base types.

typeOf[C].baseTypeSeq.toList flatMap (_ decl TermName("f") alternatives) filter (_.isDeferred)
res22: List[$r.intp.global.Symbol] = List(method f)

And then you're still not done, because that net will scoop up every deferred member, even ones for which a qualifying concrete implementation exists. So you have to reimplement all the logic for what overrides what when, and maybe there's someone on earth who has a chance at doing that correctly but it's a lonely club. For example, if the deferred f's owner is a trait, then a concrete implementation is okay even if it's defined in one of f's direct parents. But if the owner is an abstract class, then another implementation is required.

@retronym said:
As you have shown, you can't answer this question by interrogating member or overrideChain'; they both respect the "concrete always overrides deferred" rule.

It seems you are asking for RefChecksTransformer#checkAllOverrides to be refactored to expose this logic.

Here's the copy/paste version:

abstract class A           { def f: Int = 1 }
abstract class B extends A { def f: Int     }
abstract class C extends B

object Test {
  val symtab = reflect.runtime.universe.asInstanceOf[reflect.internal.SymbolTable]
  import symtab._, reflect.internal.Flags._

  def ignoreDeferred(clazz: Symbol, member: Symbol) = (
    (member.isType && member.asType.isAbstractType && !member.isFBounded) || (
         member.isJavaDefined
      && javaErasedOverridingSym(clazz, member) != NoSymbol
    )
  )

  def javaErasedOverridingSym(clazz: Symbol, sym: Symbol): Symbol =
    clazz.tpe.nonPrivateMemberAdmitting(sym.name, BRIDGE).filter(other =>
      !other.isDeferred && other.isJavaDefined && !sym.enclClass.isSubClass(other.enclClass) && {
        def uncurryAndErase(tp: Type): Type = {
          erasure.erasure(sym)(uncurry.transformInfo(sym, tp))
        }
        val tp1: Type = uncurryAndErase(clazz.thisType.memberType(sym))
        val tp2: Type = uncurryAndErase(clazz.thisType.memberType(other))
        enteringPhase(findPhaseWithName("erasure"))(tp1 matches tp2)
      })

  def abstractDecls(clazz: Symbol): List[Symbol] = {
    val result = collection.mutable.Buffer[Symbol]()
    def loop(bc: Symbol): Unit = {
      for (decl <- bc.info.decls) {
        if (decl.isDeferred && !ignoreDeferred(clazz, decl)) {
          val impl = decl.matchingSymbol(clazz.thisType, admit = VBRIDGE)
          if (impl == NoSymbol || (decl.owner isSubClass impl.owner)) {
            result += decl
          }
        }
      }
      if (bc.superClass hasFlag ABSTRACT)
        loop(bc.superClass)
    }
    loop(clazz)
    result.toList
  }

  def main(args: Array[String]): Unit = {
    println(abstractDecls(symbolOf[C]))
  }
}

scalac-hash v2.11.5 sandbox/test.scala && scala-hash v2.11.5 -nobootcp -nc Test
warning: there were three feature warnings; re-run with -feature for details
one warning found
List(method f)

@paulp said:
I would less say I am asking for that logic to be exposed (does it really look like logic which should be "blessed", but anyway) as I am asking whether "isDeferred" means anything at all, and if it does, what it is that it means. When people call "isDeferred" what is it that they might reasonably expect to discover? What is it that they do? How can obtaining the set of unimplemented members in a class be demoted to a fringe pursuit? What is reflection for?

@retronym said:
AFAIK, isDeferred just means the method has no body. What that means in the context of some subclass of that methods owner is a something of a separate question, albeit a fair one to ask.

@paulp said:
It is a separate question given that the compiler implementation detail was exported under the guise of "isDeferred", but it is the relevant question in the user-facing reflection API. Given a class, there are members which have implementations by scala's rules and there are members which don't, and one should be able to distinguish them. Even if one thinks both the implementation detail and the abstract notion must be exposed, which is doubtful, if you were forced to pick one it couldn't be the implementation detail.

To call this a "new feature" is to admit that reflection is unusable.