Better error messages for common Function/Tuple mistakes

Firstly, for `((a, b) => c): (Tuple2[A, B] => C)`, we currently
just offer "missing parameter type." Is something of a rite of
passage to know that you need `{ case (...)}`

This commit stops short DWIM, but does offer a diagnostic to guide
the user towards the supported way of destructuring a `Tuple` in
the sole argument of a `Function1`.

Secondly, another (less common?) way one might try to write a function
to destructure a single tuple argument is:

    (((a, b)) => c)

The parser now matches offers a specific error message for this, and
points out the alternatives.

In both cases, we avoid offering syntactically invalid alternatives,
by detecting names that aren't valid as variable-patterns, and
falling back to generic "paramN" in the error message.

A handly utility function to sequence a list of options is liberated
from the pattern matcher for broader use.

1 files changed, 5 insertions, 0 deletions

diff --git a/src/reflect/scala/reflect/internal/util/Collections.scala b/src/reflect/scala/reflect/internal/util/Collections.scala
index 738baddc08..7cc2952c96 100644
--- a/src/reflect/scala/reflect/internal/util/Collections.scala
+++ b/src/reflect/scala/reflect/internal/util/Collections.scala
@@ -244,6 +244,11 @@ trait Collections {
     true
   }
 
+  final def sequence[A](as: List[Option[A]]): Option[List[A]] = {
+    if (as.exists (_.isEmpty)) None
+    else Some(as.flatten)
+  }
+
   final def transposeSafe[A](ass: List[List[A]]): Option[List[List[A]]] = try {
     Some(ass.transpose)
   } catch {