| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
If we can't type check the `Foo` in `case Foo(a, b) => (a, b)`,
we should enter error symbols for `a` and `b` to avoid further
errors being reported in the case body.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An extractor is no longer required to return Option[T], and
can instead return anything which directly contains methods
with these signatures:
def isEmpty: Boolean
def get: T
If the type of get contains methods with the names of
product selectors (_1, _2, etc.) then the type and arity
of the extraction is inferred from the type of get. If
it does not contain _1, then it is a single value
extractor analogous like Option[T].
This has significant benefits and opens new territory:
- an AnyVal based Option-like class can be used which
leverages null as None, and no allocations are necessary
- for primitive types the benefit is squared (see below)
- the performance difference between case classes and
extractors should now be largely eliminated
- this in turn allows us to recapture great swaths of
memory which are currently squandered (e.g. every
TypeRef has fields for pre and args, even though these
are more than half the time NoPrefix and Nil)
Here is a primitive example:
final class OptInt(val x: Int) extends AnyVal {
def get: Int = x
def isEmpty = x == Int.MinValue // or whatever is appropriate
}
// This boxes TWICE: Int => Integer => Some(Integer)
def unapply(x: Int): Option[Int]
// This boxes NONCE
def unapply(x: Int): OptInt
As a multi-value example, after I contribute some methods to TypeRef:
def isEmpty = false
def get = this
def _1 = pre
def _2 = sym
def _3 = args
Then it's extractor becomes
def unapply(x: TypeRef) = x
Which, it need hardly be said, involves no allocations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
