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, 2 insertions, 1 deletions

diff --git a/tests/pending/run/arrayclone-new.scala b/tests/run/arrayclone-new.scala
index 5f09cd73a..8f66d1b31 100644
--- a/tests/pending/run/arrayclone-new.scala
+++ b/tests/run/arrayclone-new.scala
@@ -1,4 +1,4 @@
-import scala.reflect.{ClassTag, classTag}
+import scala.reflect.ClassTag
 
 object Test extends dotty.runtime.LegacyApp{
   BooleanArrayClone;
@@ -106,3 +106,4 @@ object PolymorphicArrayClone{
 
   testIt(mangled.it, 0, 1);
 }
+