diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2013-11-28 20:16:17 +0100 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2013-12-01 23:23:01 +0100 |
commit | e571c9cc3ee5a9e96b899285cdd2df3cdce06898 (patch) | |
tree | 7118c1dc5cf23dac0495d3c3e334be621de98916 /test/files/continuations-run/infer1.scala | |
parent | 073ebbd20ce9775260b83a78ecf9ed6a3e6d3d9e (diff) | |
download | scala-e571c9cc3ee5a9e96b899285cdd2df3cdce06898.tar.gz scala-e571c9cc3ee5a9e96b899285cdd2df3cdce06898.tar.bz2 scala-e571c9cc3ee5a9e96b899285cdd2df3cdce06898.zip |
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.
Diffstat (limited to 'test/files/continuations-run/infer1.scala')
0 files changed, 0 insertions, 0 deletions