| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Before, we looked only at the result type, which was silly.
This was originally motivated by a hack to get to the error
about conflicting paramaccessors. The error detection for that
can now be formulated more directly.
Fixes scala/scala-dev#244
|
| | |\
| | |
| | | |
Default -Xmixin-force-forwarders to true
|
| | | |
| | |
| | |
| | | |
Recovered and adapted some test cases for super calls from #5415
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also eliminates the warning when a mixin forwarder cannot be implemented
because the target method is a java-defined default method in an
interface that is not a direct parent of the class.
The test t5148 is moved to neg, as expected: It was moved to pos when
disabling mixin forwarders in 33e7106. Same for the changed error
message in t4749.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Looking at the class hierarchy around ClassTag and Manifest, the only
class that had a serialVersionUID is AnyValManifest, where the hierarchy
is something like:
trait ClassTag // extends Serializable
|- class GenericClassTag
|- trait Manifest
|- class ClassTypeManifest
|- class SingletonTypeManifest
|- ...
|- abstract class AnyValManifest // has SerialVersionUID
|- class DoubleManifest
|- ...
Note that AnyValManifest is an abstract class, so the SerialVersionUID
annotation does not help there.
This commit adds explicit SerialVersionUID annotations to (hopefully)
all subclasses of ClassTag, to make sure they are stable under
compatible changes (such as changing -Xmixin-force-forwarders).
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Super calls to indirect java parent interfaces cannot be emitted, an
error message is emitted during SuperAccessors.
The error message was missing if the super call was non-qualified,
resulting in an assertion failure in the backend.
|
| | |\ \
| | | |
| | | | |
SI-9943 sealed class does not yield SAM type
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Cannot subclass such a class. (Well, we could subclass a sealed
class in the same compilation unit. We ignore this for simplicity.)
This is a bit of a sneaky fix for this bug, but our hand
is pretty much forced by other constraints, in this intersection
of overload resolution involving built-in function types and SAMs,
and type inference for higher-order function literals (#5307).
Luckily, in this particular issue, the overloading clash seems
accidental. The `sealed` `<:<` class is not a SAM type as it
cannot be subclassed outside of `Predef`. For simplicity,
we don't consider where the SAM conversion occurs and exclude
all sealed classes from yielding SAM types.
Thanks to Miles for pointing out that `final` was missing in my
first iteration of this fix.
|
| | |\ \
| | | |
| | | | |
Fix the interface flag when re-writing a closure call to the body method
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When re-writing a closure invocation to the body method, the `itf` flag
of the invocation instruction was incorrect: it needs to be true if
the method is defined in an interface (including static methdos), not
if the method is invoked through `INVOKEINTERFACE`.
JDK 8 doesn't flag this inconsistency and executes the bytecode, but the
verifier in JDK 9 throws an `IncompatibleClassChangeError`.
Similar fixes went into e619b03.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If a non-transient lazy val is the only user of a private field in
a class, the field is nulled out at the end of the lazy initializer.
This is tested in the existing test `run/lazy-leaks.scala`.
The analysis of which fields could be nulled out was recently moved
from `mixin` to the new `fields` phase. This introduced a regression
as a reference from an inner- or companion-classes had not yet
been processed by `explicitouter` to publicise private fields.
This commit delays the analysis to mixin (after explicit outer has
done its work.)
Navigating from `foo$lzycompute()` to `foo()` to `foo` is a little
dirty now. I'm not sure whether there is a more robust way to
structure things.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a non-transient lazy val is the only user of a private field in
a class, the field is nulled out at the end of the lazy initializer.
This is tested in the existing test `run/lazy-leaks.scala`.
The analysis of which fields could be nulled out was recently moved
from `mixin` to the new `fields` phase. This introduced a regression
as a it didn't account for the richer pallete of trees and symbols
at that juncture.
This commit excludes references to private member modules from
collection of private fields, thus avoiding a later compiler
crash in the backend due to a nonsense tree trying to null
out the module symbol. It might make sense to null out the module
var, but I've opted to limit the scope of this analysis to
paramaccessors and regular fields.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
timing-based tests like these are way too sensitive to how many tests
are running in parallel, random disturbances in the AWS force (?),
and so forth.
the result being recurring intermittent failures such as
java.lang.AssertionError: assertion failed: scalaparset: 491535200 vs. javaset: 59864300
from
https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-windows/361/consoleFull
Rex and Adriaan both suggested simply deleting the tests, rather than
putting them in "pending" purgatory ("benchmarks do not belong in the
partest suite", period)
|
| |\|
| |
| | |
merge 2.12.0 onto 2.12.x [ci: last-only]
|
| | |\
| | |
| | | |
Emit local module like lazy val
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The motivation is to use the new fine-grained lock scoping that
local lazies have since #5294.
Fixes scala/scala-dev#235
Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
Fixes for DelayedInit classes capturing values
Fix scala/scala-dev#229
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Constructors rewrites references to parameter accessor methods in the
constructor to references to parameters. It avoids doing so for
subclasses of DelayedInit.
This commit makes sure the rewrite does not happen for the $outer
paramter, a case that was simply forgotten.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When a class captures an outer value, a field for that value is created
in the class. The class also gets a constructor parameter for the
captured value, the constructor will assign the field.
LambdaLift re-writes accesses to the local value (Ident trees) to the
field. However, if the statement accessing the local value will end up
inside the constructor, the access is re-written to the constructor
parameter instead. This is the case for constructor statements:
class C {
{
println(capturedLocal)
}
}
If C extends DelayedInit, the statement does not end up in C's
constructor, but into a new synthetic method. The access to
`capturedLocal` needs to be re-written to the field instead of the
constructor parameter.
LambdaLift takes the decision (field or constructor parameter) based on
the owner chain of `currentOwner`. For the constructor statement block,
the owner is a local dummy, for which `logicallyEnclosingMember` returns
the constructor symbol.
This commit introduces a special case in LambdaLift for local dummies
of DelayedInit subclasses: instead of the constructor, we use a
temporary symbol representing the synthetic method holding the
initializer statements.
|
| | |\ \ \
| | |_|/
| |/| | |
SI-9920 Avoid linkage errors with captured local objects + self types
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
An outer parameter of a nested class is typed with the self type
of the enclosing class:
```
class C; trait T { _: C => def x = 42; class D { x } }
```
leads to:
```
class D extends Object {
def <init>($outer: C): T.this.D = {
D.super.<init>();
()
};
D.this.$outer().$asInstanceOf[T]().x();
```
Note that a cast is inserted before the call to `x`.
If we modify that a little, to instead capture a local module:
```
class C; trait T { _: C => def y { object O; class D { O } } }
```
Scala 2.11 used to generate (after lambdalift):
```
class D$1 extends Object {
def <init>($outer: C, O$module$1: runtime.VolatileObjectRef): C#D$1 = {
D$1.super.<init>();
()
};
D$1.this.$outer().O$1(O$module$1);
```
That isn't type correct, `D$1.this.$outer() : C` does not
have a member `O$1`.
However, the old trait encoding would rewrite this in mixin to:
```
T$class.O$1($outer, O$module$1);
```
Trait implementation methods also used to accept the self type:
```
trait T$class {
final <stable> def O$1($this: C, O$module$1: runtime.VolatileObjectRef): T$O$2.type
}
```
So the problem was hidden.
This commit changes replaces manual typecheckin of the selection in LambdaLift with
a use of the local (erasure) typer, which will add casts as needed.
For `run/t9220.scala`, this changes the post LambdaLift AST as follows:
```
class C1$1 extends Object {
def <init>($outer: C0, Local$module$1: runtime.VolatileObjectRef): T#C1$1 = {
C1$1.super.<init>();
()
};
- C1$1.this.$outer.Local$1(Local$module$1);
+ C1$1.this.$outer.$asInstanceOf[T]().Local$1(Local$module$1);
<synthetic> <paramaccessor> <artifact> private[this] val $outer: C0 = _;
<synthetic> <stable> <artifact> def $outer(): C0 = C1$1.this.$outer
}
```
|
| | |\ \
| | | |
| | | | |
Avoid mismatched symbols in fields phase
|
| | | | |
| | | |
| | | |
| | | | |
Also narrow scope of afterOwnPhase.
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The info of the var that stores a trait's lazy val's computed value
is expressed in terms of symbols that exist before the fields phase.
When we're implementing the lazy val in a subclass of that trait,
we now see symbols created by the fields phase, which results
in mismatches between the types of the lhs and rhs in the assignment
of `lazyVar = super.lazyImpl`.
So, type check the super-call to the trait's lazy accessor before our
own phase. If the lazy var's info depends on a val that is now
implemented by an accessor synthesize by our info transformer,
we'll get a mismatch when assigning `rhs` to `lazyVarOf(getter)`,
unless we also run before our own phase (like when we were
creating the info for the lazy var).
This was revealed by Hanns Holger Rutz's efforts in compiling
scala-refactoring's test suite (reported on scala-internals).
Fixes scala/scala-dev#219
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GenBCode, the new backend in Scala 2.12, subtly changed
the way that synchronized blocks are emitted.
It used `java/lang/Throwable` as an explicitly named exception
type, rather than implying the same by omitting this in bytecode.
This appears to confuse HotSpot JIT, which reports a error
parsing the bytecode into its IR which leaves the enclosing method
stuck in interpreted mode.
This commit passes a `null` descriptor to restore the old pattern
(the same one used by javac.) I've checked that the JIT warnings
are gone and that the method can be compiled again.
|
| | |\
| | |
| | | |
Avoid omitting constant typed vals in constructors
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix for regression in 2.12.0-RC1 compiling shapeless tests.
They were given the same treatment as vals that are
members of classes on the definition side without the
requisite transformation of references to the val to
fold the constant into references.
This commit limits the transform to members of classes.
Co-Authored-By: Miles Sabin <miles@milessabin.com>
|
| | |\ \
| | | |
| | | | |
SD-225 Use a "lzycompute" method for module initialization
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The monitors and module instantation were inliuned into the module accessor
method in b2e0911. However, this seems to have had a detrimental impact on
performance. This might be because the module accessors are now above the
"always inline" HotSpot threshold of 35 bytes, or perhaps because they
contain monitor-entry/exit and exception handlers.
This commit returns to the the 2.11.8 appraoch of factoring
the the second check of the doublecheck locking into a method.
I've done this by declaring a nested method within the accessor;
this will be lifted out to the class level by lambdalift.
This represents a slight deviation from the implementation strategy used
for lazy accessors, which create a symbol for the slowpath method in
the info transform and generate the corresponding DefDef as a class
member. I don't believe this deviation is particular worrisome, though.
I have bootstrapped the compiler through this commit and found that
the drastic regression in compiling the shapeless test suite is solved.
|
| | |/ |
|
| |\ \
| | |
| | | |
SI-9936 SeqLike.indexWhere starts at zero
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This follows the Scaladoc, and makes
```
"abcdef".indexOf('c', -1)
```
work like
```
"abcdef".toVector.indexOf('c', -1)
```
|
| |/
|
|
|
|
|
| |
It'd be good to use the latest version. From sbt-jmh version 0.2.10,
Flight Recorder / Java Mission Control is available[1], which would be nice.
[1] https://github.com/ktoso/sbt-jmh#using-oracle-flight-recorder
|
| |\
| |
| |
| |
| | |
SD-208 Restore 2.11 names for arrayOps implicits
Fix scala/scala-dev#208
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The restriction for super calls to methods defined in indirect super
classes introduced in a980fde was over-restrictive. In particular, it
ruled out a valid code pattern to select a method from a superclass
when an unqualified `super` would resolve to an override defined in a
trait (example in the commit as a test).
|
| |\ \
| | |
| | | |
Fixes to mixin forwarders
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
JUnit 4 does not support default methods. For better user experience,
this commit makes the compiler generate mixin forwarders for inherited
trait methods that carry a JUnit annotation.
The -Yjunit-trait-methods-no-forwarders flag disables this behavior.
This supersedes the scala-js/scala-2.12-junit-mixin-plugin compiler
plugin.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a call super[T].m resolves to a method A.m where A is a class, but
not the direct superclass of the current class, there is no way to
emit an invocation of A.m: `invokespecial A.m` will resolve to B.m
where B is the superclass of the current class.
This commit adds an error message in this case.
Note that this is similar to an existing error message for qualified
super calls to a non-direct superclass:
class A { def m = 1 }
class B extends A { override def m = 2 }
class C extends B { override def m = super[A].m }
Gives "error: A does not name a parent class of class C".
If the user means to call method m in the superclass, he can write an
unqualified `super.m`.
An similar error message is introduced if A is a Java-defined interface
(and m is a default method), and A is not a direct parent of the current
class. In this case `invokespecial A.m` is invalid bytecode. The
solution is to add A as a direct parent of the current class.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With -Xgen-mixin-forwarders the compiler eagerly creates mixin
forwarders for methods inherited from traits, even if the JVM method
resolution would pick the correct default method.
When generating a such a forwarder for a Java-defined default method,
the mixin forwarder invokes the default method directly using
`invokespecial` (for Scala-defined trait methods, the forwarder uses
the static `m$` method that is generated for every trait method).
An `invokespecial` call is only legal if the named interface is a
direct parent of the current class. If this is not the case, we don't
generate the mixin forwarder and emit a warning.
In the tests there's also an example where a mixin forwarder is
required for correctness, but cannot be added because the corresponding
`invokespecial` call would be invalid. In this case we emit an error.
This is similar to what we already do for other super calls to Java-
defined default methods. The difference is that the super call is not
written by the user but generated by the mixin forwarder. The solution
is the same: add the interface as a direct parent.
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
Fields: expand lazy vals during fields, like modules
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Mostly refactorings and catching up with doc updates.
Some changes to flag handling, removing some redundancy,
and making lazy fields and modules a bit more consistent
in their flags. They now uniformly carry LAZY or MODULEVAR.
Before, LAZY was dropped because mixin had some lazy val
logic. No longer.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The goal is to avoid emitting unneeded `BoxedUnit` values,
which are the result of adapting a `Unit`-typed expression
inside a `synchronized(...)` to the erased type of
`synchronized`'s argument -- `Object`.
The proposed solution gives `synchronized` a polymorphic
type (the info of the type param is still erased so that
bounds checking works in the erased type system), so that
an application `synchronized(println("boo"))` erases to
`synchronized[Unit])(println("boo"))`, and no boxing is
performed on the `println("boo")` argument, whose expected
type is now `Unit` instead of `Object`.
|
