Change implicit resolution rule wrt implicit parameters

The method with fewer parameters wins now over methods with more parameters.
The reason for the change is i3430.scala, with

    Nil.sum

Here, orderings for any type are eligible implied instances for `sum`'s implicit `Ordering`
parameter. If we prioritize arguments with implicit parameters, we have to try all
tuple orderings which themselves take as many implicit parameters as the tuple has elements.
This leads to an infinite recursion with very broad fanout, so the observed effect is that
the compiler hangs.

By prioritizing shorter implicit parameter lists, we avoid this problem.

Author: odersky

compiler/src/dotty/tools/dotc/typer/Applications.scala

@@ -1411,10 +1411,10 @@ trait Applications extends Compatibility { self: Typer with Dynamic =>
     val strippedType2 = stripImplicit(fullType2, +1)
 
     val result = compareWithTypes(strippedType1, strippedType2)
-    if (result != 0 || !ctx.typerState.test(implicit ctx => strippedType1 =:= strippedType2))
+    if (result != 0)
       result
     else if (implicitBalance != 0)
-      -implicitBalance.signum
+      implicitBalance.signum
     else if ((strippedType1 `ne` fullType1) || (strippedType2 `ne` fullType2))
       compareWithTypes(fullType1, fullType2)
     else

docs/docs/reference/changed-features/implicit-resolution.md

@@ -114,10 +114,8 @@ affect implicits on the language level.
     An alternative A is _more specific_ than an alternative B if
 
      - the relative weight of A over B is greater than the relative weight of B over A, or
-     - the relative weights are the same, and the returned types of A and B are
-       unifiable, and A takes more inferable parameters than B, or
+     - the relative weights are the same, and A takes fewer inferable parameters than B, or
      - the relative weights and the number of inferable parameters are the same, and
-       the returned types of A and B are unifiable, and
        A is more specific than B if all inferable parameters in either alternative are
        replaced by regular parameters.
 

tests/run/implicit-specifity.scala

@@ -12,19 +12,31 @@ object Generic {
   implied showGen[T] given Generic for Show[T] = new Show[T](2)
 }
 
+class Generic2
+object Generic2 {
+  opaque type HiPriority = AnyRef
+  implied showGen[T] for (Show[T] & HiPriority) = new Show[T](2).asInstanceOf
+}
+
+class SubGen extends Generic
+object SubGen {
+  implied for SubGen
+}
 object Contextual {
   trait Context
   implied ctx for Context
   implied showGen[T] given Generic for Show[T] = new Show[T](2)
   implied showGen[T] given Generic, Context for Show[T] = new Show[T](3)
+  implied showGen[T] given SubGen for Show[T] = new Show[T](4)
 }
 
 object Test extends App {
   assert(Show[Int] == 0)
   assert(Show[String] == 1)
-  assert(Show[Generic] == 2) // showGen beats fallback due to longer argument list
+  assert(Show[Generic] == 1)   // showGen loses against fallback due to longer argument list
+  assert(Show[Generic2] == 2)  // ... but the opaque type intersection trick works.
 
   { import implied Contextual._
-    assert(Show[Generic] == 3)
+    assert(Show[Generic] == 4) // shorter, more specific implicit parameter list wins
   }
 }

tests/run/implied-specifity.scala

@@ -1,5 +1,5 @@
 // Shows that now implicit parameters act as a tie-breaker.
-// The alternative with more implicit parameters wins.
+// The alternative with fewer implicit parameters wins.
 case class Show[T](val i: Int)
 
 class Generic
@@ -21,7 +21,7 @@ object Test extends App {
     def foo[T]: Show[T] = new Show[T](2)
   }
 
-  assert(a.foo[Int].i == 2)
-  assert(b.foo[Int].i == 1)
+  assert(a.foo[Int].i == 1)
+  assert(b.foo[Int].i == 2)
 
 }