Revert <: Product requierment in pattern matching

The change in question broke the following pattern, commonly used in name based pattern matching:

```scala
object ProdEmpty {
  def _1: Int = ???
  def _2: String = ???
  def isEmpty = true
  def get = this
}
```

This type define both `_1` and `get` + `isEmpty` (but is not <: Product). After #1938, `ProdEmpty` became eligibles for both product and name based pattern. Because "in case of ambiguities, *Product Pattern* is preferred over *Name Based Pattern*", isEmpty wouldn't be used, breaking the scalac semantics.

1 files changed, 2 insertions, 5 deletions

diff --git a/compiler/src/dotty/tools/dotc/typer/Applications.scala b/compiler/src/dotty/tools/dotc/typer/Applications.scala
index c4d3e2292..7e17abbcd 100644
--- a/compiler/src/dotty/tools/dotc/typer/Applications.scala
+++ b/compiler/src/dotty/tools/dotc/typer/Applications.scala
@@ -48,9 +48,6 @@ object Applications {
     ref.info.widenExpr.dealias
   }
 
-  def canProductMatch(tp: Type)(implicit ctx: Context) =
-    extractorMemberType(tp, nme._1).exists
-
   /** Does `tp` fit the "product match" conditions as an unapply result type
    *  for a pattern with `numArgs` subpatterns?
    *  This is the case of `tp` has members `_1` to `_N` where `N == numArgs`.
@@ -72,7 +69,7 @@ object Applications {
   }
 
   def productArity(tp: Type)(implicit ctx: Context) =
-    if (canProductMatch(tp)) productSelectorTypes(tp).size else -1
+    if (defn.isProductSubType(tp)) productSelectorTypes(tp).size else -1
 
   def productSelectors(tp: Type)(implicit ctx: Context): List[Symbol] = {
     val sels = for (n <- Iterator.from(0)) yield tp.member(nme.selectorName(n)).symbol
@@ -114,7 +111,7 @@ object Applications {
         getUnapplySelectors(getTp, args, pos)
       else if (unapplyResult isRef defn.BooleanClass)
         Nil
-      else if (canProductMatch(unapplyResult))
+      else if (defn.isProductSubType(unapplyResult))
         productSelectorTypes(unapplyResult)
           // this will cause a "wrong number of arguments in pattern" error later on,
           // which is better than the message in `fail`.