Take expected result type into account more often for overloading resolution

Previously, the expected result type of a FunProto type was ignored and taken into
account only in case of ambiguities. arrayclone-new.scala shows that this is not enough.
In a case like

    val x: Array[Byte] = Array(1, 2)

we typed 1, 2 to be Int, so overloading resulution would give the Array.apply of
type (Int, Int*)Array[Int]. But that's a dead end, since Array[Int] is not a subtype
of Array[Byte].

This commit proposes the following modified rule for overloading resulution:

  A method alternative is applicable if ... (as before), and if its result type
  is copmpatible with the expected type of the method application.

The commit does not pre-select alternatives based on comparing with the expected
result type. I tried that but it slowed down typechecking by a factor of at least 4.
Instead, we proceed as usual, ignoring the result type except in case of
ambiguities, but check whether the result of overloading resolution has a
compatible result type. If that's not the case, we filter all alternatives
for result type compatibility and try again.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/dotty/tools/dotc/typer/ProtoTypes.scala b/src/dotty/tools/dotc/typer/ProtoTypes.scala
index c7efe45b7..9a012c30e 100644
--- a/src/dotty/tools/dotc/typer/ProtoTypes.scala
+++ b/src/dotty/tools/dotc/typer/ProtoTypes.scala
@@ -46,7 +46,7 @@ object ProtoTypes {
      *  fits the given expected result type.
      */
     def constrainResult(mt: Type, pt: Type)(implicit ctx: Context): Boolean = pt match {
-      case _: FunProto =>
+      case pt: FunProto =>
         mt match {
           case mt: MethodType =>
             mt.isDependent || constrainResult(mt.resultType, pt.resultType)