| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Reduce # of creation methods and make TypeNames
simple derived names from TermNames.
|
| |\
| |
| | |
Fix #2142: Skolemize arguments of dependent methods if necessary
|
| | |
| |
| |
| | |
Change name and align order of parameters.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We now consider a type also as stable if it refers
to an ExprType whose result type is stable.
The previous commit made pos/z1720.scala break, because it
skolemized unstable argument types. This commit makes the test
pass again.
|
| | |
| |
| |
| | |
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.
|
| |\ \
| | |
| | | |
Upgrade to sbt 0.13.15
|
| |/ / |
|
| |\ \
| | |
| | | |
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.
|
| |\ \ \
| |/ /
|/| | |
Fix #2201: Less aggressive type application reduction for better inference
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Refactor lambda types
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- 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
|
| | | | | |
|
| | | | | |
|
