| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
| | | |
| | | |
| | | | |
This was missing before, led to errors not being detected.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Strictly speaking, all the info about a skolem type is printed, e.g.
A(?2)
But it's reassuring to have an explanation line like
?2 is an unknown value of type A
|
| | | | |
| | | |
| | | |
| | | | |
These were not printed before, fell back to toString method.
|
| |\ \ \ \
| | | | |
| | | | | |
Add enum exhaustivity checking
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Now the algorithm is the same as in the paper.
|
| | | | | | |
|
| | | | | | |
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | | |
A new kind of child annotation that points to the term symbol representing an
enum value.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Fix #2198: Don't widen module singletons
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since module classes are a compiler-generated construct that's not directly
visible to programmers, it seems better not to automatically widen a module
singleton to its underlying class.
Fixes #2198.
|
| |\ \ \ \
| | | | |
| | | | | |
Fix #2188: Do cbn transform also on Selects
|
| | |/ / /
| | | |
| | | |
| | | | |
These can arise as a result of an explicit outer transform.
|
| |\ \ \ \
| | |_|/
| |/| | |
Fix #2192: Follow supertypes when determining whether an expect type …
|
| | |/ /
| | |
| | |
| | | |
function type
|
| |\ \ \
| |/ /
|/| | |
Fix #2220: Change handling of package objects and tweak hk type inference
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Invalidate packageObj cache when entering a package object
2. Prefer package object members over same-named package members
unless we are in the scala package
3. Exclude package objects from no-double-bindings checks, since
package objects may now be visited before indexing them.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we believed that reducing type applications did not affect
type inference as long as the reduced type constructor had the same
arity as the unreduced one, for example reducing `Foo[X, Y]` is fine
when `Foo` is defined as:
type Foo[A, B] = Bar[A, B]
but not when it's defined as:
type Foo[A] = Bar[A, A]
But this is not a sufficient condition: the bounds of the type
constructor arguments also matter for type inference, so we need to be
more strict and disallow reductions in cases like:
type Foo[A, B] = Bar[B, A]
and:
type Foo[A, B] = Bar[A, Int]
|
| |\ \
| | |
| | | |
Deterministically randomises test compilation order
|
| | | |
| | |
| | |
| | | |
The previous implementation would compile tests in different orders from machine to machine, depending on the order in which *.scala files are listed by the operating system.
|
| |\ \ \
| |_|/
|/| | |
fix #2166: unpickling of shared CaseDef
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- split LambdaType.equals into two equals so that tests
are more specific (also avoids type testing against
a trait)
- re-order cases in some pattern matches with the aim to
(1) move common cases earlier, (2) move more expensive
trait type tests later.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Two benefits: (1) less code. (2) finding subtle bugs about
parameter dependent method types. By merging with PolyTypes
we are forced to take parameter dependencies into account.
|
| | | |
| | |
| | |
| | |
| | | |
It's too surprising to leave it as a type proxy. In all circumstances except
erasure, it is not true that a PolyType is somehow the same as its result type.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Use fromParams instead.
|
| | | |
| | |
| | |
| | |
| | | |
- Use TypeLambda instead of PolyType.
- Further harmonize factory operations
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Replace with LambdaType
|
| | | |
| | |
| | |
| | | |
Replace with ParamRef
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
... to distinguish between HK(proxy) and *(ground) types.
Also, refactor some more methods to keep it DRY.
|
| | | |
| | |
| | |
| | | |
Also, rename LambdaOver{Type,Term}s to {Type,Term}Lambda
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Use an abstract type instead.
|
| | | |
| | |
| | |
| | | |
Trying to bring PolyTypes closer to TypeLambdas
|
| | | |
| | |
| | |
| | |
| | |
| | | |
MethodTypes have paramTypes whereas PolyTypes have paramBounds.
We now harmonize by alling both paramInfos, and parameterizing
types that will become common to both.
|
| | | |
| | |
| | |
| | |
| | | |
and generalize MethodParam to ParamRef, and
TypeParamInfo to ParamInfo
|
| | | |
| | |
| | |
| | |
| | | |
It was a red herring. Symbolic names are expanded anyway to $plus / $minus,
so they can't be confused with a variance prefix.
|
