| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \
| | | |
| | | | |
Move the inlining of value class methods before Erasure
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
VCInline is split into two phases:
- VCInlineMethods (before Erasure) replaces value class method calls
by calls to extension methods
- VCElideAllocations (after Erasure) handles == and optimizing the
unboxing of a boxed value class, as VCInline did before.
This should not affect anything currently, but in the future we will have
phases before Erasure that mangle names (like TypeSpecializer, see #630),
being able to put these phases after VCInlineMethods means that
VCInlineMethods does not need to know anything about how these phases
mangle names, this reduces the coupling between phases. The trade-off is
that VCInlineMethods needs to deal with type parameters and multiple
parameter lists whereas VCInline didn't.
|
| |\ \ \
| | | |
| | | | |
Don't add lower bounds of abstract types to the implicit scope
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As the spec[1] says:
"The parts of a type T are [...] if T is an abstract type, the parts of
its upper bound;"
[1]: http://www.scala-lang.org/files/archive/spec/2.11/07-implicits.html#implicit-parameters
|
| |/ /
| |
| |
| |
| | |
The productPrefix of a case class should be the name of the class itself
to match Scala 2.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
What is checked: A self type T is a subtype of all
selftypes of classes refernced by T. That is, a self type
has to subsume all self types of its required type. Ot,
otherwise said, requirements must be closed; you cannot
discover new ones in following them.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A TypeRef can have be unresolved, either because it refers to something that's missing
from the classpath or because of transitive self type references. Instead of crashing
in sigName, we now report the error.
Achieved by defining a new exception type, MissingType, which derives from TypeError.
This catches t7933.scala, now integrated in the neg/selfreq.scala. The problem there was
a reference to AbsSettings, which was not a member of StandardScalaSettings.this,
but was a member of the required type of AbsSettings, which itself appeared in the
required type of StandardScalaSettings. We will outlaw in the next commit such transitive
required references.
Also collapsed TypeError and FatalTypeError. It was a misnomer anyway. Fatal were those
type errors that were caught and reported!
Open: Where else we should check for unresolved NamedTypes.
|
| |\ \
| |/
|/| |
Fix/dependent methods
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Necessary to make implicit resolution of type-level peano numbers work.
The current commit makes takes the inimal steps to make this happen. We
could also consider sharpening using followAlias every type we constrain
a result, or every time we adapt a type.
|
| | |
| |
| |
| | |
Now handles included test if toplevel implicit is given, but not yet without.
|
| | |
| |
| |
| | |
This confirms that SI-6359 does not apply to Dotty.
|
| |\ \
| | |
| | | |
Avoid crasher when first token of a program is in error
|
| | | |
| | |
| | |
| | | |
Seems partest adds code to the sources so that line numbers are not the same.
|
| | | |
| | |
| | |
| | | |
Line numbers were wrong in previous file.
|
| | |/
| |
| |
| |
| | |
This used to give a crash in SourcePositiom, promoted by feeding
its calculations with a negative offset.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
According to SIP 15 a value class C must obey the following restrictions:
C may not have secondary constructors.
C may not declare fields (other than the parameter of a value class).
C may not contain object definitions.
C may not have initialization statements.
These are enforced by this commit. We are still missing restrictions on
value class paremeters. We should review what the right set of conditions
is (probably we want to admit non-vals, and maybe even multiple
parameters).
|
| | | |
|
| | |
| |
| |
| |
| | |
So far no error was raised for illegal inheritance
from final or sealed classes.
|
| | |
| |
| |
| |
| |
| |
| | |
Reason: A lifted module is no longer a module (i.e. singleton object) in the scope
to which it is lifted.
Fixes #689.
|
| | |
| |
| |
| | |
Uncommented parts that were left accidentally commented out when debugging.
|
| | |
| |
| |
| |
| | |
The file consisted of just a deprecation warning. Not sure what was deprecated; neither dotty
nor scalac find anything wrong with it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
Uncomment two lines that were commented out by accident.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | | |
| | | |
| | | |
| | | | |
Ws disabled by accident.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We seem to have an instability where the testing framework influences what numbers
anonymous classes are given. We have to deal with this, but not now. For the moment
I am masking numbers from the test output.
|
| | | | |
| | | |
| | | |
| | | | |
Difference was in generated number for anonymous classes only.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\| | |
| |/ /
|/| | |
Fix/#659 lambdalift proxies
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If an inner class has proxy fields, we missed so far the assignment sfrom
the proxy parameters in the primary constructor of the class to the proxy
fields.
Test case tries several variations of this.
|
| | | |
| | |
| | |
| | | |
Even if an explicit outer accessor was a method, it got a TermRef as type.
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
