| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The line content to display should include the whole line,
inclusive of embedded line breaks, and any control chars
should be displayed in unicode escape.
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Source lines were counted by "line break chars", including FF.
Clients of `pos.line` seem to all expect the ordinary line num,
so that is what they get.
Unicode processing now precedes line ending processing.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Deprecate automatic () insertion in argument lists
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This promotes the () insertion warning from -Ywarn-adapted-args to a
deprecation warning. -Xfuture tunrs it into a compiler error.
Auto tupling remains unchanged for now.
The tests have been fixed the following way:
- Warnings caused by general sloppiness (Try(), Future(), ...) have been
fixed.
- Warnings which raise interesting questions (x == (), ...) received an
updated checkfile for now.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix non-deterministic <:< for deeply nested types
|
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Taken from "On Decidability of Nominal Subtyping with Variance"
(Pierce, Kennedy), which was implemented in 152563b.
Part of the implementation (SubTypePair) will be changed in the
following commit to fix the non-deterministic errors typechecking
heavily nested types involving aliases or annotations.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
reshuffles names for blackbox/whitebox contexts, changes bundle notation
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per Jason’s feedback, this commit handles overloaded constructors
in macro bundles. The backend now checks that we have a constructor of
a correct type. The frontend now prohibits multiple constructors altogether.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Adjusts bundle notation to read `class Bundle(val c: Context)` instead of
`class Bundle extends Macro`. This avoids calling compileLate in the
macro compiler and associated tooling problems.
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Improves name-based patmat.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Name-based pattern matcher needed some hardening against
unapply methods with the right name but wrong types. Only
isEmpty methods which return Boolean are acceptable.
Catching it directly rather than indirectly also allowed
for better error messages.
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This emerges from a recent attempt to eliminate pattern matcher
related duplication and to bake the scalac-independent logic
out of it. I had in mind something a lot cleaner, but it was
a whole lot of work to get it here and I can take it no further.
Key file to admire is PatternExpander.scala, which should
provide a basis for some separation of concerns.
The bugs addressed are a CCE involving Tuple1 and an imprecise
warning regarding multiple pattern crushing.
Editorial: auto-tupling unapply results was a terrible idea which
should never have escaped from the crib. It is tantamount to
purposely throwing type safety down the toilet in the very place
where people need type safety the most. See SI-6111 and SI-6675 for
some other comments.
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
SI-2066 Plug a soundness hole higher order type params, overriding
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
PolyType-s parameterized by higher order type parameters (HOTPs)
should only be relatable with <:< or =:= if the variances of their
type parameters line up. This is only enforced for HOTPs defined in
method type arguments.
Invariant type parameters subsume variant ones. Concretely, as
described by @S11001001:
> A method taking [F[_]] can implement a method taking [F[+_]].
> Likewise, a method taking [F[_[+_]]] can implement a method
> taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]],
> and so on, the variance subsumption flipping at each step.
>
> This is just the opposite of the variance for passing type
> parameters to either instantiate types or call methods; a F[+_]
> is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument,
> and so on.
>
> All of the above rules can be duplicated for contravariant positions
> by substituting - for +. Also, something similar happens for
> weakening/strengthening bounds, I believe.
These cases are tested in the `// okay` lines in `neg/t2066.scala`.
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
new hooks in AnalyzerPlugins to enable macro experimentation
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Interestingly enough, despite of the implementation surface being
quite noticeable, it is enough to hijack just `enterSym` and typechecking
of stats for packages, templates and blocks in order to enable macro annotations.
That and `ensureCompanionObject`, which I couldn't abstract away so far.
An architectural note: given that a hooked method is called `X`,
there are two implementations of this method. `pluginsX` is defined in
AnalyzerPlugins.scala and lets macro plugins customize `X`.
`standardX` is defined next to `X` and provides a default implementation.
Finally `X` is changed to trivially forward to `pluginsX`.
Existing and future callers of `X` now can be completely oblivious of the
introduced hooks, because calls to `X` will continue working and will be
correctly hooked. This makes the infrastructure more robust.
The only downside is that in case when a macro plugin wants to call
into the default implementation, it needs to call `standardX`, because
`X` will lead to a stack overflow. However, in my opinion this not a big
problem, because such failures are load and clear + for every `pluginsX`
we actually provide documentation that says what is its standard impl is.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Macro defs are linked to macro impls by the virtue of MacroImplBinding
structures that are persisted between compilation runs serialized within
instances of macroImpl annotations.
Along with the evolution of our macro engine, we sometimes have to evolve
the format of MacroImplBinding, which means that it has to be versioned.
Version mismatches are checked upon every macro expansion, ensuring that
macros that we expand were compiled with exactly the same version of the
macro engine that we’re running.
That’s all really cool apart from the fact that version mismatches result
in aborting the entire compilation with an obscure message without giving
a hint about the culprits.
This commit improves the situation by providing pretty per-expansion
compilation errors that tell the programmer what macro expansions are
at fault and what macro engines were used to compile them.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Back then, when we needed separate macro expanders for both applications
and unapplications, it made sense to have two different methods that
do macro expansions.
However, after @paulp’s upgrade of the pattern matching engine, we no longer
need a dedicated expander for unapply, so I’m removing it and renaming
`macroExpandApply` to just `macroExpand`.
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
SI-8052 Disallow `macro` as an identifier
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Note that the change could look a lot cleaner, at the cost of returning
more generic error messages. I decided that at least for 2.11 I'll keep
scalac remembering that macro was a standard identifier name once, so
that we can point out more precisely what's wrong with users' code.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
makes boxity of fast track macros configurable
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously, all built-in macros were assumed to be whitebox, but that’s
actually not the case. Just quasiquote macros have to be whitebox, while
the rest can be blackbox.
This also fixes SI-8091, because blackbox macros are typechecked differently
and therefore the necessary implicit conversion kicks in. If `f”...”` were
to remain a whitebox macro, then due to the changes introduced in commit
https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77
we would have to explicitly ascribe its expansion as String to achieve the same effect.
After I made reify blackbox, several tests had to be changed, because
we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`.
Also, a number of less obvious corrections had to be applied, because
things like `reify(<constant>).splice` have stopped being optimized away
due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`,
making it ineligible for constant folding.
Moreover, this change forced me to adjust our approach to positioning
blackbox wrappings, because after being changed to blacbox and starting using
wrappings, f”...” interpolators used in the compiler started crashing
-Yrangepos builds. Now wrapping Typed nodes are assigned with transparent
positions.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-7777 SI-8006 assorted fixes for dynamics
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since mkInvoke, the applyDynamic/selectDynamic/etc desugarer, is disconnected
from typedNamedApply, the applyDynamicNamed argument rewriter, the latter
doesn’t know whether it needs to apply the rewriting because the application
has just been desugared or it needs to hold on because it’s already performed
a desugaring on this tree.
This commit introduces the attachment that links these translation facilities,
preventing infinite applyDynamicNamed desugarings.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
(master) codifies the state of the art wrt SI-8104
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As it was discovered in SI-8104, whiteboxity doesn’t apply equally to
type parameters and type members of materialized type classes.
During implicit search and subsequent type inference, whitebox type parameters
are consistently erased to wildcards, whereas whitebox type members sometimes
remain as is and get in the way of signature conformance checks.
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows,
it looks like it is possible to overload applyDynamic, even though a
straightforward way is closed. This commit codifies the pattern proposed
by @paulp and makes sure that it doesn’t break in the future.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-6120 Suppress extra warnings
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a mere polish for the fix to allow multiple warnings.
Sensibility checks in refchecks were shown to be redundant.
This commit includes a mild refactor to reduce tabbage, and
uses a local var to flag that a warning has already been emitted.
It would be better to have the checks return true if warned,
to facilitate `nonSensically || unrelatedly`, etc., but that's
a lot of `else false`.
The check files that were updated with the redundant warnings
are reverted.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Currently, accessors for private local trait fields are added
very late in the game when the `Mixin` tree transformer treats the
trait. By contrast, fields with weaker access have accessors created
eagerly in `Namers`.
// Mixin#addLateInterfaceMembers
val getter = member.getter(clazz)
if (getter == NoSymbol) addMember(clazz, newGetter(member))
`addMember` mutates the type of the interface to add the getter.
(This seems like a pretty poor design: usually if a phase changes
types, it should do in an `InfoTransformer`.)
However, if an inner class or anonymous function of the trait
has been flattened to a spot where it precedes the trait in the
enclosing packages info, this code hasn't had a chance to run,
and the lookup of the getter crashes as mixins `postTransform`
runs over a selection of the not-yet-materialized getter.
// Mixin#postTransform
case Select(qual, name) if sym.owner.isImplClass && !isStaticOnly(sym) =>
val iface = toInterface(sym.owner.tpe).typeSymbol
val ifaceGetter = sym getter iface
This commit ensures that `Flatten` lifts inner classes to
a position *after* the enclosing class in the stats of the
enclosing package.
Bonus fix: SI-7012 (the followup ticket to SI-6231 / SI-2897)
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
jrudolph/w/fix-typo-that-that-occurs-twice-in-error-messages
fix typo in error messages
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Test case for recently improved unchecked warning
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prior to https://github.com/scala/scala/pull/2848, the enclosed
test compiled without warning and printed:
true
false
Features interacting:
- implicit class tags to enable type patterns on abstract types
- type tests on compound types.
I think the unchecked warning is acceptable for now.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8024 Fix inaccurate message on overloaded ambiguous ident
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We were outputing a the unattractive `package package`;
now we opt for `package object pack`.
Under `-Ydebug`, we still go to the "accurate" mode of the
old `toString` implementation, which differentiates package objects
vs package object classes.
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`Symbol#owner` of an overloaded symbol doesn't necessarily correspond
to the owner of any of the alternatives, and as such it shouldn't
be used in error message.
neg/t8024.scala actually represents a progression since 2.10.3;
the ambiguity was not reported. I bisected the change to
https://github.com/scala/scala/pull/1554.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-6780 Better handling of cycles in in-scope implicit search
|
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Implicit searches in the body of implicit members with inferred
types were leading to cycles. Before we used to resolve that
by saying there were no implicits in scope at all; now we just
skip the current context and still include the enclosing implicits.
Care is taken not to cache results under these circumstances.
This entails reworking `Context#implicitss` so that:
- the implicit info cache only contains implicits from the current
level. The List[List[_]] is now contructed on demand;
- we can detect cycles by setting `implicitsCacheRunId` to -1 during
the computation. The outer implicits when we encounter that.
- we avoid caching when we hit a cycle or when the owner is uninitialized.
|
|\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
Plugins get a class path
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Let -Xplugin specify a class path (or multiple of them).
Each entry can be a jar or dir, and the first entry to supply
a plugin descriptor defines the plugin to load.
If no plugin is found on the path, then issue a warning if `-Xdev`.
This honors the legacy silent treatment (which scala-ide tests for).
In the proposed scheme, each plugin gets a class loader so that
plugins are isolated from each other.
Presumably, if compiler plugins were a rich ecosystem, in which
shared dependencies were required in incompatible versions, this
would have become a requirement by now.
(Updated with a `DirectTest` that uses two plugins, but keeping
the following as documentation.)
Partest can't do multiple plugins yet, but this is what it looks like:
```
skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,another,other foo.scala
skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,other -Xplugin-disable:another foo.scala
skalac -Xplugin:sample.jar:useful.jar:util,sample.jar:useful.jar:util -Xplugin-require:sample foo.scala
```
The manual test shows three plugins with various permutations of jars and dirs.
The manual test demonstrates that plugins only see classes on their class path:
```
Initializing test.plugins.SamplePlugin
needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful)
useful.Useful? Success(class useful.Useful)
Initializing more.plugins.AnotherPlugin
needful.Needful? Success(class needful.Needful)
useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful)
Initializing other.plugins.OtherPlugin
```
Disabling a plugin results in a message instead of silent suppression:
```
Disabling plugin another
```
The duplicate plugin class test must still be honored:
```
Ignoring duplicate plugin sample (test.plugins.SamplePlugin)
Initializing test.plugins.SamplePlugin
needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful)
useful.Useful? Success(class useful.Useful)
```
If the path is bad, then missing classes will report which plugin induced
the error:
```
Error: class not found: util/Probe required by test.plugins.SamplePlugin
Error: class not found: util/Probe required by more.plugins.AnotherPlugin
Initializing other.plugins.OtherPlugin
needful.Needful? Success(class needful.Needful)
useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful)
error: Missing required plugin: sample
error: Missing required plugin: another
two errors found
```
|
| | | | | |
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit performs a number of preliminary refactoring needed to
implement unliftable:
1. Replace previous inheritance-heavy implementation of Holes with
similar but much simpler one. Holes are now split into two different
categories: ApplyHole and UnapplyHole which correspondingly represent
information about holes in construction and deconstruction quasiquotes.
2. Make Placeholders extract holes rather than their field values. This
is required to be able to get additional mode-specific information
from holes (e.g. only ApplyHoles have types).
3. Bring ApplyReifier & UnapplyReifier even closer to the future where
there is just a single base Reifier with mode parameter.
Along the way a few bugs were fixed:
1. SI-7980 SI-7996 fail with nice error on bottom types splices
2. Use asSeenFrom instead of typeArguments in parseCardinality.
This fixes a crash if T <:< Iterable[Tree] but does not itself
have any type arguments.
3. Fix spurious error message on splicing of Lists through Liftable[List[T]]
|
|\ \ \ \
| | | | |
| | | | | |
streamlines refchecking undesired symbol properties
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Unifies `checkDeprecated`, `checkMigration` and `checkCompileTimeOnly`
into a single centralized point of reference that is now consistently
called from `checkTypeRef`, `transformIdent` and `transformSelect`.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the new focus on quasiquotes in macro implementations, we now have
to change the way how inference of macro def return types works.
Previously, if the return type of a macro def wasn’t specified, we looked into
the signature of its macro impl, took its return type (which could only
be c.Expr[T]) and then assigned T to be the return type of the macro def.
We also had a convenient special case which inferred Any in case when
the body of the macro impl wasn’t an expr. That avoided reporting spurious
errors if the macro impl had its body typed incorrectly (because in that
case we would report a def/impl signature mismatch anyway) and also provided
a convenience by letting macro impls end with `???`.
However now we also allow macro impls to return c.Tree, which means that
we are no longer able to do any meaningful type inference, because c.Tree
could correspond to tree of any type.
Unfortunately, when coupled with the type inference special case described
above, this means that the users who migrate from exprs to quasiquotes
are going to face an unpleasant surprise. If they haven’t provided
explicit return types for their macro defs, those types are going to be
silently inferred as `Any`!
This commit plugs this loophole by prohibiting type inference from
non-expr return types of macro impls (not counting Nothing). Moreover,
it also deprecates c.Expr[T] => T inference in order to avoid confusion
when switching between exprs and quasiquotes.
|
|\ \ \
| | | |
| | | | |
better error messages for various macro definition errors
|
| |/ / |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|