| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An extractor pattern `X(p)` should type check for any `X.unapply`/`X.unapplySeq`
that returns an `Option[_]` -- previously we were confused about the case where
it was an `Option[(T1, ... , Tn)]`. In this case, the expected type for the
pattern `p` is simply `(T1, ... , Tn)`.
While I was at it, tried to clean up unapplyTypeList and friends (by replacing them by extractorFormalTypes).
From the spec:
8.1.8 ExtractorPatterns
An extractor pattern x(p1, ..., pn) where n ≥ 0 is of the same syntactic form as a constructor pattern.
However, instead of a case class, the stable identifier x denotes an object which has a member method named unapply or unapplySeq that matches the pattern.
An unapply method in an object x matches the pattern x(p1, ..., pn) if it takes exactly one argument and one of the following applies:
n = 0 and unapply’s result type is Boolean.
n = 1 and unapply’s result type is Option[T], for some type T.
the (only) argument pattern p1 is typed in turn with expected type T
n > 1 and unapply’s result type is Option[(T1, ..., Tn)], for some types T1, ..., Tn.
the argument patterns p1, ..., pn are typed in turn with expected types T1, ..., Tn
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current design of error trees complicates the design of reflection
library, and introduces sometimes unnecessary boilerplate and since I
do not want to stall that work I am reverting all the changes related
to error trees. A different design is currently under consideration but
work will be done on separate branch on github.
Revisions that got reverted:
r25705, r25704 (partially), r25673, r25669, r25649, r25644, r25621, r25620, r25619
Review by odersky and extempore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are no more direct calls to context.error from Typers and Infer,
so more work needs to be done to finish it for Implicits and Namers.
I am pushing it to trunk so that all of you can share my pain (and
complain). Please do not add any more context.error randomly in that
code, instead deal with it appropriately (by creating specific error
tree).
I was trying to be as informative when it comes to error tree names
as possible, but if you feel like changing names to something more
appropriate then feel free to do so. When it comes to printing error
messages I tried to follow test suite as closily as possible but
obviously there were few changes to some tests (mostly positive, I
believe).
On my machine performance drawback was neglible but I am working on more
aggressive caching to reduce the penalty of containsError() calls even
more. Any suggestions welcome.
At the moment the code supports both styles i.e. throwing type errors
for the cases that are not yet handled and generating error trees. But
in the future we will drop the former completely (apart from cyclic
errors which can pop up almost everywhere).
Review by odersky, extempore and anyone who feels like it.
|
