Don't prefer concrete over deferred methods in lookup in Java classes

[lrytz]

For scala/bug#12892.

[lrytz]

scala> def f(l: java.util.List[Object]) = l.sort(_.toString compareTo _.toString)
                                                 ^
       error: missing parameter type for expanded function ((<x$1: error>, x$2) => x$1.toString.compareTo(x$2.toString))
                                                                      ^
       error: missing parameter type for expanded function ((<x$1: error>, <x$2: error>) => x$1.toString.compareTo(x$2.toString))

not immediately obvious to me why this broke, will check later.

[som-snytt]

Glad you are taking concrete action and not deferring.

[som-snytt]

I refreshed my poor memory about find members, and also JLS on inheritance. Interfaces are simple, but the rule for classes is first concrete, then if you didn't inherit a concrete m you can inherit an abstract-or-default member from super classes and interfaces.

So a default method in a Java interface does not count as concrete.

This alternative tweak maybe, in walkBaseClasses, to say always take interface methods as non-concrete:

          val flags =
            if (currentBaseClass.isJavaDefined && currentBaseClass.isTrait) flags0 | DEFERRED
            else flags0

The test with inference passes:

ok 1 - pos/t12892b.scala

(I opened a PR out of curiosity. Must go shower and return library books now.)

I'll try to understand what it indicates. #10580