| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| | |
1. Make genericType a trait instead of a class.
2. Make TypeLambda a type proxy
3. Split underlying in TypeProxy into underlying and superType
4. Cleanups in many other places
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Taking the signature over a type with uninstantiated type variables
means that the signature can change later, once we instantiate the
type variable. We handle this by recording uninstantiated positions
of signatures and fixing them in PostTyper, when type variables are
instantiated.
- This allows to drop the kludge of "normalizing" in derivedRefinedType
Dropping this initially revealed the problems with under-determined
signatures. Now that these problems are fixed, we can drop for good.
|
| |
| |
| |
| |
| |
| |
| | |
Make them each inherit from common BaseType GenericType.
That way we avoid inheriting accidentally stuff from PolyType in TypeLambda.
Also, Fix adaptation of type lambdas. Don't confuse them with PolyTypes.
|
|/ |
|
|\
| |
| | |
Fix #856: Handle try/catch cases as catch cases if possible.
|
| |
| |
| |
| |
| |
| |
| | |
Previously they were all lifted into a match with the came cases.
Now the first cases are handled directly by by the catch. If one
of the cases can not be handled the old scheme is applied to to it
and all subsequent cases.
|
|\ \
| |/
|/| |
Check non-deferred declarations are implemented
|
| | |
|
| |
| |
| |
| |
| | |
GenBCode checks if class already has static initialiser,
the check is fooled if class inherited a static initialisers.
|
| |
| |
| |
| | |
This broke lazy vals, as unsafe offsets were not initialised.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Nicely spotted by Ycheck.
|
| |
| |
| |
| |
| |
| |
| | |
Now moveStatics can correctly create static constructors for objects.
Those static constructors would later be merged with synthetic module
initialisers by GenBCode. This is a bit of magic, it would be good
to move all this into this phase.
|
| |
| |
| |
| |
| | |
Unlink the static from the old scope,
and don't drop top-level trees that are not TypeDefs.
|
| |
| |
| |
| |
| |
| | |
There used to be a rare test when companion class and companion
object would have gotten the very same offset,
causing undefined behaviour in runtime.
|
| | |
|
| |
| |
| |
| | |
It's not clear how they should be implemented.
|
| |
| |
| |
| |
| |
| |
| | |
As a funny side-effect this allows to execute arbitrary code in static
initialisers:
@static val a: Unit = {println("loaded")}
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fix gives the position and refactors the code that gave off
warnings, but it also begs the question - should we be able to handle
emitting a switch for the following case:
```scala
(x: @switch) match {
case 'a' if somePredicate(x) => // ...
case 'b' => // ...
}
```
Currently if there is a guard, the patternmatcher will fail to emit
a switch. Scalac can handle these cases currently.
|
|\
| |
| | |
Fixes to lambdalift that prevent memory leaks.
|
| | |
|
| |
| |
| |
| | |
See t5375.scala for details.
|
| |
| |
| |
| |
| |
| |
| | |
Before there was an implicit assumption that static methods are only
present on objects.
This assumption is invalidated both by linker optimizations and the new
fix to lambdalift.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CollectDependencies had incorrect handling of `Ident`s.
If it had ever met an `Ident` to a symbol defined outside of current
owner-chain(e.g. Predef.println) it would issue narrowTo(enclosingClass).
This is very conservative and leads to memory leaks
even in trivial lambdas.
My lambda-lift-foo groes stronger :-)
|
| |
| |
| |
| |
| |
| |
| | |
One drawback with this approach is that the type seems to propagate.
I.e. if the return type of an expression is `repeated` then the
enclosing variable will get the `repeated` type instead of getting the
expected `Seq` type
|
| | |
|
|\ \
| | |
| | | |
Fix bootstrap
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add bytecode checking infrastructure
|
| | | | |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Annotated values are encapsulated in a `ConcreteAnnotation`, as such,
the statement `tpe isRef defn.IntClass` would yield false despite the
annotated reference being an Int.
The tpe is now unwrapped if it has an annotation. If the transformation
fails despite having the annotation the compiler will warn.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The tests `i1059.scala` and `t3480.scala` are failing due to a bug
in pattern matcher that evaluates the `x` in `List(x: _*)` incorrectly.
Concerned issue: #1276
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| |
| |
| | |
Name, Symbol, Denotation, Type.
This uncovered two nonsensical comparisons, one in CollectEntryPoints,
the other in DottyBackendInterface.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot throw a merge error if atSignature does not give
a unique single denotation. Counter example is compiling dotty itself,
where we get a false negative during bridge generation.
Instead, atSigature needs to return a normal denotation, and we
need to check separately where required that a denotation is in
fact a SingleDenotation.
|
| |
| |
| |
| |
| |
| |
| |
| | |
When finding two symbols in the same class that have the same signature
as seen from some prefix, issue a merge error.
This is simpler and more robust than the alternative of producing an overloaded
denotation and dealing with it afterwards.
|
|/
|
|
|
|
|
|
| |
Once we do not merge methods with same signature anymore
we got an ambiguous overload between the constructors of
Any and Object after erasure (when all Any methods are
moved to Object). To avoid this, we map the Any constructor
to the Object constructor after erasure.
|
| |
|
|
|
|
|
|
|
|
| |
There's no point transforming annotations that come from
classfiles. It's inefficient to do so and it's also risky
because it means we'd have to make sense of Scala-2 generated trees.
This should avoid the error in #1222.
|
|
|
|
|
|
|
|
|
|
| |
There's a trap otherwise that, when in a class inheriting
from Context (and with it Reporting) a call to println will
go to this.println and therefore might not print at all, if
the current context buffers messages. I lost a lot of time
on this on several occasions when I scratched my head why
a simple debug println would not show. Better avoid this in
the future for myself and others.
|