| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
#2152 shows that dependent result type parameters can end up in
the types of terms, so we have to eliminate them. If we don't we
get orphan parameters in pickling.
Fix method name and comment
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Take parameter dependencies into account when typechecking arguments.
|
| |
|
|
|
| |
Now we never match `? { name: T }` with types that
have only a private `name` member. This is what scalac does, too.
|
| |
|
|
| |
... unless they would be accessible in the given context.
|
| |
|
|
|
| |
Need to use fresh PolyParams instead of WildcardTypes
if constraint is committable.
|
| |
|
|
|
|
| |
We approximate dependencies to parameters by Wildcards. This was already
done in one place, is now done in other places as well, instead of doing nothing for
dependent methods.
|
| |
|
|
|
| |
No reason why we should not - normalize handles implicit
methods just fine. This fixes type errors in test HLists.scala.
|
| |
|
|
|
|
|
|
|
|
| |
f-bounded-case-class.scala exhibited a StackOverflow in wildApprox before
the fixes. The problem was due to F-bounds.
Note: wildApprox is performance critical. I ran timed-bootstrap-repeated
a couple of times to verify that the changes did not affect runtimes in
significant ways. We should also watch out for a slowdown in the
benchmark tests.
|
| |
|
|
|
| |
If the expected type is Unit, any parameterless member should
be considered applicable when doing overloading resolution.
|
| |
|
|
|
| |
When faced with a denotation that combines parameterless and nullary method
definitions (toString is a common example), ignore any redundant () applications.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We interpolate a type variable if the current tree contains the type variables
binding tree. Previously, this was the application owning the variable. However,
sometimes this tree is transformed so that the containment test fails, and
type variables are instantiated too late (in the case of #1757 this was never).
We fix this by
- setting the binding tree to the type tree that first contains the type variable
- making sure that tree is never copied literally anywhere else.
It's a tricky dance, but I believe we got it right now.
|
| |
|
