Spurious auto-application warnings with java methods with -Xsource:2.14

[neko-kai]

With -Xsource:2.14 my build produces warnings when calling java methods without parentheses, which is the currently recommended Scala style:

Auto-application to `()` is deprecated. Supply the empty argument list `()` explicitly to invoke method toString,
[warn] or remove the empty argument list from its definition (Java-defined methods are exempt).
[warn] In Scala 3, an unapplied method like this will be eta-expanded into a function.
[warn]         case o => o.toString

However, toString is a Java method, which as the warning itself suggests, is excluded from deprecation!

[eed3si9n]

@Kaishh Thanks for the report.

I agree with exempting toString. It's curious whether the compiler thinks of toString as Java-defined or its own via scala.Any.

[eed3si9n]

For a potential contributor, a good place to start would be looking into the changeset in scala/scala#7660.

[eed3si9n]

See also @adriaanm's description in scala/scala#7660:

(4.2) condition for auto-application by -Xsource level:

• until 2.14: none (assuming condition for (4.3) was not met)

• in 3.0: meth.isJavaDefined
  TODO decide -- currently the condition is more involved to give slack to
  Scala methods overriding Java-defined ones; I think we should resolve that
  by introducing slack in overriding e.g. a Java-defined def toString()
  by a Scala-defined def toString. This also works better for dealing
  with accessors overriding Java-defined methods.

  The current strategy in methodSig is problematic:

  // Add a () parameter section if this overrides some method with () parameters
  val vparamSymssOrEmptyParamsFromOverride =

  This means an accessor that overrides a Java-defined method gets a
  MethodType instead of a NullaryMethodType, which breaks lots of
  assumptions about accessors

[som-snytt]

scala> typeOf[String].member(TermName("toString")).asMethod.isJavaDefined
res1: Boolean = true

scala> case class K(k: String)
defined class K

scala> typeOf[K].member(TermName("toString")).asMethod.isJavaDefined
res2: Boolean = false

scala> class C
defined class C

scala> typeOf[C].member(TermName("toString")).asMethod.isJavaDefined
res3: Boolean = true

[joroKr21]

scala> case class Foo(override val toString: String)
defined class Foo

scala> typeOf[Foo].member(TermName("toString")).typeSignature
res1: $r.intp.global.Type = => String

scala> case class Bar(b: String) { override def toString: String = "" }
defined class Bar

scala> typeOf[Bar].member(TermName("toString")).typeSignature
res2: $r.intp.global.Type = ()String

🤔

[som-snytt]

Thanks @joroKr21

scala> class C { override val toString = "hi" }
defined class C

scala> new C().toString()
                       ^
       error: not enough arguments for method apply: (i: Int)Char in class StringOps.
       Unspecified value parameter i.

scala> class C { override def toString = "hi" }
defined class C

scala> new C().toString()
res1: String = hi

Both cases are covered by 5.1.4 on overriding, except that defs cannot eliminate a param list, by the special rule mentioned there.

Did I say that correctly? It's so late here, I'm going to sleep. Probably a good spec is legible at bedtime.

[eed3si9n]

Here's my PR for this - scala/scala#8296