| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/ /
| | |
| | |
| | | |
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
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
It seems we need a more refined way to deal with non-variant variables
in pattern matches. See branch change-patmat-undet for a WIP. For the
moment we disable -strict to be able to compile latest version of dotty. (reverted from commit c8fe830f8a382eb965c2231064fa286ee8f0a4ec)
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
It seems we need a more refined way to deal with non-variant variables
in pattern matches. See branch change-patmat-undet for a WIP. For the
moment we disable -strict to be able to compile latest version of dotty.
|
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | |
| | |
| | |
| | | |
and fix typo
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This leads to a slight overall simplification, harmonizes pickle
format with internal representation, and makes MethodTypes and
PolyTypes more similar to each other.
I believe the change is useful as it is, but in particular it is
a useful step for an eventual unification of MethodTypes and
PolyTypes.
|
|\ \ \
| | | |
| | | | |
Add "enum" construct
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
- rename utility methods
- generate utility methods also for object cases
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Infer type arguments for enum paraments from corresponding type
parameter bounds. This only works if the type parameter in question
is variant and its bound is ground.
|
| | | | |
|