| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
There is a diff, but a minor one. Instead of
(T? >: Int <: Int)
we get
(T? = Int) after pickling.
|
| |
|
|
|
|
| |
The original IterableSelfRec is not syntactically legal after
the hk changes. I attempted to fix, but there's still a type error.
Need to investigate whether this is a true error or a bug.
|
| | |
|
| |
|
|
| |
This reverts commit a43d39ad719978fbb36663f336c1c7cd2c4da1e0.
|
| |\
| |
| | |
Ycheck that methods defined in ClassInfo exist in tree.
|
| | | |
|
| | |
| |
| |
| |
| | |
Making a correct fix could take some time,
and I want to find other issues before I start working on this one.
|
| | | |
|
| |/
|
|
| |
Fixes #688
|
| |\
| |
| | |
Fix/dependent methods
|
| | | |
|
| | |
| |
| |
| | |
Now handles included test if toplevel implicit is given, but not yet without.
|
| | |
| |
| |
| |
| |
| |
| | |
Reason: A lifted module is no longer a module (i.e. singleton object) in the scope
to which it is lifted.
Fixes #689.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thistypes erased to the underlying class. This is wrong. When seen as part of some other type,
a ThisType has to erase to the erasure of the underlying type (i.e. the erasure if the selftype
of the class). unittest-collections.scala failed with a MethodNotFound error because the erasure
was computed incorrectly.
On the other hand, a tree with a ThisType type, should keep the type, analogous to a
tree with a TermRef type.
|
| |\ \
| |/
|/| |
Avoid junk produced by Constraint#replace.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were two instances where a constraint undergoing a replace would still refer
to poly params that are no longer bound after the replace.
1. In an ordering the replaced parameters was n ot removed from the bounds of the others.
2. When a parameter refers to the replaced parameter in a type, (not a TypeBounds), the
replaced parameter was not replaced.
We now have checking in place that in globally committable typer states, TypeVars are not instantiated
to PolyParams and (configurable) that constraints of such typer states are always closed.
Fixes #670.
|
| |\ \
| | |
| | | |
Closes #579 Implement mini-phase for classOf[T]
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Fix/#646 array addition
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously `viewExists(X, Y)` failed if there were ambiguous
implicit conversions from X to Y. This is too fragile, as
demonstrated by test case run/array-addition.scala. Here,
the `genericArrayOps` implicit was not inserted because its
result type `Array[?T]` was deemed to be incompatible with
`? { +: : ? }`. It was incompatible because there were multiple
implicits that added :+ to arrays of various element types.
But once `genericArrayOps` gets applied, the type parameter
`?T` of the array result is fixed, and the ambuity goes away.
The scenario shows that we should not test for ambiguous implicits
in viewExists. Such a test is fragile because it depends on the
progress of type inference when the test is made. It's preferable
to just test for any implicit conversion to exist and to check
for ambiguities later, when the implicit conversion is actually
applied. This has also the potential of speeding up implicit search
in situations where `viewExists` is called often (e.g. when coupled
with overloading resolution).
|
| |\ \ \ \
| |/ / /
|/| | | |
Fix/#652 erase constructors
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously this was only done in secondary constructors; need
to do it in primary constructor as well to avoid "reference to
this before super" problems.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Proxy references in constructors can't be left as fields because
they can happen before the supercall.
|
| | |/ /
| | |
| | |
| | |
| | | |
Map references to outer accessors in secondary constructors to outer parameters. This
was the second source of "reference to this before super call" errors.
|
| |\ \ \
| |_|/
|/| | |
Fix checking whether types are instantiable.
|
| | | |
| | |
| | |
| | |
| | | |
The logic for checking aginst the self type was wrong, as demonstrated
by pos/checkInstantiable.scala.
|
| |\ \ \
| |_|/
|/| | |
Fix/#655 eta expansion
|
| | | |
| | |
| | |
| | | |
Failure to do a widen caused by-name parameters to go undetected.
|
| |\ \ \
| |/ /
|/| | |
Fix sequence matching.
|
| | | |
| | |
| | |
| | | |
Was also fixed in this PR.
|
| | | |
| | |
| | |
| | |
| | | |
Call drop method directly if class derives from sequence.
I do not understand how callRuntime works in scalac. Calling this method requires implicit search.
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the expected result type of a FunProto type was ignored and taken into
account only in case of ambiguities. arrayclone-new.scala shows that this is not enough.
In a case like
val x: Array[Byte] = Array(1, 2)
we typed 1, 2 to be Int, so overloading resulution would give the Array.apply of
type (Int, Int*)Array[Int]. But that's a dead end, since Array[Int] is not a subtype
of Array[Byte].
This commit proposes the following modified rule for overloading resulution:
A method alternative is applicable if ... (as before), and if its result type
is copmpatible with the expected type of the method application.
The commit does not pre-select alternatives based on comparing with the expected
result type. I tried that but it slowed down typechecking by a factor of at least 4.
Instead, we proceed as usual, ignoring the result type except in case of
ambiguities, but check whether the result of overloading resolution has a
compatible result type. If that's not the case, we filter all alternatives
for result type compatibility and try again.
|
| |\ \
| | |
| | | |
Fix #643 - Scala2 unpickling now sets NoInits flag for interfaces.
|
| | |/
| |
| |
| |
| |
| |
| | |
Refinement classes and their members could give spurious stale symbol errors if the
symbol is loaded in a different run than the classfile containing it. The problem
is that refinement classes do not form part of the scope of their owners. The fix
assumes that refinement classes are always "stillValid".
|
| |\ \
| |/
|/| |
Enable tests that pass, move macro tests to disabled.
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
Methods like + can have multiple parameters. In that case
+= also takes multiple parameters.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
As the comment in the code says:
"In general, a bridge is needed when the signature of the closure method after
Erasure contains an ErasedValueType but the corresponding type in the functional
interface is not an ErasedValueType."
So we need to check if _at least one_ of the type needs to be adapted,
not if _all of them_ need to, the use of "forall" was an error.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Fix #522.
|
