| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-8040 Improve unused warnings
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Warn for unused `case X(x) =>` but, as an escape hatch,
not for `case X(x @ _) =>`. The latter form is deemed
documentary. (Named args could serve a similar purpose,
`case X(x = _) =>`.)
An attachment is used to mark the bound var, and the
symbol position is used to correlate the identifier
with the variable that is introduced. This mechanism
doesn't work yet when only a single var is defined.
|
| |/
|
|
| |
This reverts commit eb5c51383a63c5c3420e53ef021607ff5fd20296.
|
| |\ |
|
| | |\
| | |
| | | |
SI-4700 The thrilling continuation to the infix type printing saga.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
```
scala> import scala.annotation.infix
import scala.annotation.infix
scala> @infix class &&[T, U]
defined class $amp$amp
scala> def foo: Int && Boolean = ???
foo: Int && Boolean
```
|
| |\ \ \
| |/ /
|/| | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make sure that methods annotated with varargs are properly mixed-in. This commit
splits the transformation into an info transformer (that works on all symbols, whether
they come from source or binary) and a tree transformer.
The gist of this is that the symbol-creation part of the code was moved to the UnCurry
info transformer, while tree operations remained in the tree transformer. The newly
created symbol is attached to the original method so that the tree transformer can still
retrieve the symbol.
A few fall outs:
- I removed a local map that was identical to TypeParamsVarargsAttachment
- moved the said attachment to StdAttachments so it’s visible between reflect.internal
and nsc.transform
- a couple more comments in UnCurry to honour the boy-scout rule
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
VarHandles bring a host of new "polymorphic signature" methods to
the Java 9 standard library. This commit updates the way we detect
such methods to look at the absense/presense of the
`PolymorphicSignature` annotation, so as to include these (and any
future additions.)
When we see applications of such methods, we disable adaptation
of argument and return types.
Tested manually with JDK9-ea:
```
Welcome to Scala 2.12.2-20161208-165912-3de1c0c (Java HotSpot(TM) 64-Bit Server VM, Java 9-ea).
Type in expressions for evaluation. Or try :help.
scala> import java.lang.invoke._, scala.runtime.IntRef
import java.lang.invoke._
import scala.runtime.IntRef
scala> val varHandle = MethodHandles.lookup().in(classOf[IntRef]).findVarHandle(classOf[IntRef], "elem", classOf[Int]);
varHandle: java.lang.invoke.VarHandle = java.lang.invoke.VarHandleInts$FieldInstanceReadWrite@7112ce6
scala> varHandle.getAndSet(ref, 1): Int
res5: Int = 0
scala> varHandle.getAndSet(ref, 1): Int
res6: Int = 1
```
Inspecting bytecode shows the absense of box/unboxing:
```
object Test {
import java.lang.invoke._, scala.runtime.IntRef
val varHandle = MethodHandles.lookup().in(classOf[IntRef]).findVarHandle(classOf[IntRef], "elem", classOf[Int]);
def main(args: Array[String]): Unit = {
val i : Int = varHandle.getAndSet(IntRef.zero, 1)
}
}
```
```
public void main(java.lang.String[]);
Code:
0: aload_0
1: invokevirtual #28 // Method varHandle:()Ljava/lang/invoke/VarHandle;
4: invokestatic #34 // Method scala/runtime/IntRef.zero:()Lscala/runtime/IntRef;
7: iconst_1
8: invokevirtual #40 // Method java/lang/invoke/VarHandle.getAndSet:(Lscala/runtime/IntRef;I)I
11: istore_2
12: return
```
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make sure that methods annotated with varargs are properly mixed-in. This commit
splits the transformation into an info transformer (that works on all symbols, whether
they come from source or binary) and a tree transformer.
The gist of this is that the symbol-creation part of the code was moved to the UnCurry
info transformer, while tree operations remained in the tree transformer. The newly
created symbol is attached to the original method so that the tree transformer can still
retrieve the symbol.
A few fall outs:
- I removed a local map that was identical to TypeParamsVarargsAttachment
- moved the said attachment to StdAttachments so it’s visible between reflect.internal
and nsc.transform
- a couple more comments in UnCurry to honour the boy-scout rule
|
| |\ \ \
| | | |
| | | | |
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.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Essentially, we fuse mixin and lazyvals into the fields phase.
With fields mixing in trait members into subclasses, we
have all info needed to compute bitmaps, and thus we can
synthesize the synchronisation logic as well.
By doing this before erasure we get better signatures,
and before specialized means specialized lazy vals work now.
Mixins is now almost reduced to its essence: implementing
super accessors and forwarders. It still synthesizes
accessors for param accessors and early init trait vals.
Concretely, trait lazy vals are mixed into subclasses
with the needed synchronization logic in place, as do
lazy vals in classes and methods. Similarly, modules
are initialized using double checked locking.
Since the code to initialize a module is short,
we do not emit compute methods for modules (anymore).
For simplicity, local lazy vals do not get a compute method either.
The strange corner case of constant-typed final lazy vals
is resolved in favor of laziness, by no longer assigning
a constant type to a lazy val (see widenIfNecessary in namers).
If you explicitly ask for something lazy, you get laziness;
with the constant-typedness implicit, it yields to the
conflicting `lazy` modifier because it is explicit.
Co-Authored-By: Lukas Rytz <lukas@lightbend.com>
Fixes scala/scala-dev#133
Inspired by dotc, desugar a local `lazy val x = rhs` into
```
val x$lzy = new scala.runtime.LazyInt()
def x(): Int = {
x$lzy.synchronized {
if (!x$lzy.initialized) {
x$lzy.initialized = true
x$lzy.value = rhs
}
x$lzy.value
}
}
```
Note that the 2.11 decoding (into a local variable and a bitmap) also
creates boxes for local lazy vals, in fact two for each lazy val:
```
def f = {
lazy val x = 0
x
}
```
desugars to
```
public int f() {
IntRef x$lzy = IntRef.zero();
VolatileByteRef bitmap$0 = VolatileByteRef.create((byte)0);
return this.x$1(x$lzy, bitmap$0);
}
private final int x$lzycompute$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
C c = this;
synchronized (c) {
if ((byte)(bitmap$0$1.elem & 1) == 0) {
x$lzy$1.elem = 0;
bitmap$0$1.elem = (byte)(bitmap$0$1.elem | 1);
}
return x$lzy$1.elem;
}
}
private final int x$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
return (byte)(bitmap$0$1.elem & 1) == 0 ?
this.x$lzycompute$1(x$lzy$1, bitmap$0$1) : x$lzy$1.elem;
}
```
An additional problem with the above encoding is that the `lzycompute`
method synchronizes on `this`. In connection with the new lambda
encoding that no longer generates anonymous classes, captured lazy vals
no longer synchronize on the lambda object.
The new encoding solves this problem (scala/scala-dev#133)
by synchronizing on the lazy holder.
Currently, we don't exploit the fact that the initialized field
is `@volatile`, because it's not clear the performance is needed
for local lazy vals (as they are not contended, and as soon as
the VM warms up, biased locking should deal with that)
Note, be very very careful when moving to double-checked locking,
as this needs a different variation than the one we use for
class-member lazy vals. A read of a volatile field of a class
does not necessarily impart any knowledge about a "subsequent" read
of another non-volatile field of the same object. A pair of
volatile reads and write can be used to implement a lock, but it's
not clear if the complexity is worth an unproven performance gain.
(Once the performance gain is proven, let's change the encoding.)
- don't explicitly init bitmap in bytecode
- must apply method to () explicitly after uncurry
|
| | |/
|/|
| |
| |
| |
| | |
Rather than putting the code of a trait method body into a static method,
leave it in the default method. The static method (needed as the target
of the super calls) now uses `invokespecial` to exactly call that method.
|
| | |
| |
| |
| | |
Also deprecate the TraitSetter annotation.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An existing optimization in `Constructors` elides the outer
field in member and local classes, if the class doesn't use
the outer reference. (Member classes also need to be final,
which is a secret handshake to say we're also happy to weaken
prefix matching in the pattern matcher.)
That optimization leaves the constructor signature as is: the
constructor still accepts the outer instance, but does not store
it. For member classes, this means that we can separately compile
code that calls the constructor.
Local classes need not be hampered by this constraint, we could
remove the outer instance from the constructor call too.
Why would we want to do this?
Let's look at the case before and after this commit.
Before:
```
class C extends Object {
def foo(): Function1 = $anonfun();
final <static> <artifact> def $anonfun$foo$1($this: C, x: Object): Object = new <$anon: Object>($this);
def <init>(): C = {
C.super.<init>();
()
}
};
final class anon$1 extends Object {
def <init>($outer: C): <$anon: Object> = {
anon$1.super.<init>();
()
}
}
```
After:
```
class C extends Object {
def foo(): Function1 = $anonfun();
final <static> <artifact> def $anonfun$foo$1(x: Object): Object = new <$anon: Object>(null);
def <init>(): C = {
C.super.<init>();
()
}
};
final class anon$1 extends Object {
def <init>($outer: C): <$anon: Object> = {
anon$1.super.<init>();
()
}
}
```
However, the status quo means that a lambda that
This in turn makes lambdas that refer to such classes serializable
even when the outer class is not itself serialiable.
I have not attempted to extend this to calls to secondary constructors.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The body of lambdas is compiled into a synthetic method
in the enclosing class. Previously, this method was a public
virtual method named `fully$qualified$Class$$anonfun$n`.
For lambdas that didn't capture a `this` reference, a static
method was used.
This commit changes two aspects.
Firstly, all lambda impl methods are now emitted static.
An extra parameter is added to those that require a this
reference.
This is an improvement as it:
- allows, shorter, more readable names for the lambda impl method
- avoids pollution of the vtable of the class. Note that javac uses
private instance methods, rather than public static methods. If
we followed its lead, we would be unable to support important use
cases in our inliner
Secondly, the name of the enclosing method has been included in
the name of the lambda impl method to improve debuggability and
to improve serialization compatibility. The serialization improvement
comes from the way that fresh names for the impl methods are
allocated: adding or removing lambdas in methods not named "foo" won't
change the numbering of the `anonfun$foo$n` impl methods from methods
named "foo". This is in line with user expectations about anonymous
class and lambda serialization stability. Brian Goetz has described
this tricky area well in:
http://cr.openjdk.java.net/~briangoetz/eg-attachments/lambda-serialization.html
This commit doesn't go as far a Javac, we don't use the hash of the
lambda type info, param names, etc to map to a lambda impl method name.
As such, we are more prone to the type-1 and -2 failures described there.
However, our Scala 2.11.8 has similar characteristics, so we aren't going
backwards.
Special case in the naming: Use "new" rather than "<init>" for constructor enclosed
lambdas, as javac does.
I have also changed the way that "delambdafy target" methods are identifed.
Rather than relying on the naming convention, I have switched to using a
symbol attachment. The assumption is that we only need to identify them
from within the same compilation unit.
This means we can distinguish impl metbods for expanded functions
(ones called from an `apply` method of an ahead-of-time expanded
anonfun class), from those that truly end up as targets for lambda
metafactory. Only the latter are translated to static methods in
this patch.
|
| | |
| |
| |
| | |
Also adds a warning on junit test methods that compile as default
methods.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot use the expected type to track whether a Function node
targets a SAM type, as the expected type may be erased (see test
for an example).
Thus, the type checker attaches a SAMFunction attachment to a
Function node when SAM conversion is performed in adapt. Ideally,
we'd move to Dotty's Closure AST, but that will need a
deprecation cycle.
Thanks to Jason for catching my mistake, suggesting the fix and
providing the test.
Both the sam method symbol and sam target type must be tracked,
as their relationship can be complicated (due to inheritance).
For example, the sam method could be defined in a superclass (T)
of the Function's target type (U).
```
trait T { def foo(a: Any): Any }
trait U extends T { def apply = ??? }
(((x: Any) => x) : U).foo("")
```
This removes some of the duplication in deriving the sam method
from the expected type, but some grossness (see TODO) remains.
|
| |\ \
| | |
| | | |
Use invokedynamic for structural calls, symbol literals, lambda ser.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous encodings created static fields in the enclosing class
to host caches. However, this isn't an option once emit code in default
methods of interfaces, as Java interfaces don't allow private static
fields.
We could continue to emit fields, and make them public when added to
traits.
Or, as chosen in this commit, we can emulate a call-site specific
static field by using invokedynamic: when the call site is linked,
our bootstrap methid can perform one-time computation, and we can
capture the result in the CallSite.
To implement this, I've allowed encoding of arbitrary invokedynamic
calls in ApplyDynamic.
The encoding is:
ApplyDynamic(
NoSymbol.newTermSymbol(TermName("methodName")).setInfo(invokedType)
Literal(Constant(bootstrapMethodSymbol)) :: (
Literal(Constant(staticArg0)) :: Literal(Constant(staticArgN)) :: Nil
) :::
(dynArg0 :: dynArgN :: Nil)
)
So far, static args may be `MethodType`, numeric or string literals, or
method symbols, all of which can be converted to constant pool entries.
`MethodTypes` are transformed to the erased JVM type and are converted
to descriptors as String constants.
I've taken advantage of this for symbol literal caching and
for the structural call site cache.
I've also included a test case that shows how a macro could target this
(albeit using private APIs) to cache compiled regexes.
I haven't managed to use this for LambdaMetafactory yet, not sure
if the facility is general enough.
|
| |/ /
| |
| |
| |
| |
| | |
... instead of scala.collection.mutable.StringBuilder to benefit from
JVM optimizations. Unfortunately primitives are already boxed in erasure
when they end up in this part of the backend.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
All class internal names that are referenced from a class being
compiled should be referenced through their ClassBType. This makes
sure that the ClassBType is cached in `classBTypeFromInternalName`,
which is required during classfile writing: when ASM computes stack
map frames, we need to answer subtyping queries, for which we need
to look up the ClassBTypes.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous methods to identify method invocations that can be
optimized, such as `isPredefAutoBox`, were String-based. Now we
obtain class and method signatures from symbols through the
BTypes infrastructure.
We also piggy-back on specialization's type transformer to create
all specialized subclasses of Tuple1/Tuple2. We'll do the same in
the future for FunctionN, but the current JFunctionN are written
in Java and specialized artisanally.
|
| | |
| |
| |
| |
| |
| |
| | |
Allow annotating individual callsites @inline / @noinline using an
annotation ascription
c.foo(): @inline
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A trio of problems were hampering autocompletion of annotations.
First, given that that annotation is written before the annotated
member, it is very common to end parse incomplete code that has a
floating annotation without an anotatee.
The parser was discarding the annotations (ie, the modifiers) and
emitting an `EmptyTree`.
Second, the presetation compiler was only looking for annotations
in the Modifiers of a member def, but after typechecking annotations
are moved into the symbol.
Third, if an annotation failed to typecheck, it was being discarded
in place of `ErroneousAnnotation`.
This commit:
- modifies the parser to uses a dummy class- or type-def tree,
instead of EmptyTree, which can carry the annotations.
- updates the locator to look in the symbol annotations of the
modifiers contains no annotations.
- uses a separate instance of `ErroneousAnnotation` for each
erroneous annotation, and stores the original tree in its
`original` tree.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using the "uncurry-erased" type (the one after the uncurry phase) can
lead to incorrect tree transformations. For example, compiling:
```
def foo(c: Ctx)(l: c.Tree): Unit = {
val l2: c.Tree = l
}
```
Results in the following AST:
```
def foo(c: Ctx, l: Ctx#Tree): Unit = {
val l$1: Ctx#Tree = l.asInstanceOf[Ctx#Tree]
val l2: c.Tree = l$1 // no, not really, it's not.
}
```
Of course, this is incorrect, since `l$1` has type `Ctx#Tree`, which is
not a subtype of `c.Tree`.
So what we need to do is to use the pre-uncurry type when creating
`l$1`, which is `c.Tree` and is correct. Now, there are two
additional problems:
1. when varargs and byname params are involved, the uncurry
transformation desugares these special cases to actual
typerefs, eg:
```
T* ~> Seq[T] (Scala-defined varargs)
T* ~> Array[T] (Java-defined varargs)
=>T ~> Function0[T] (by name params)
```
we use the DesugaredParameterType object (defined in
scala.reflect.internal.transform.UnCurry) to redo this desugaring
manually here
2. the type needs to be normalized, since `gen.mkCast` checks this
(no HK here, just aliases have to be expanded before handing the
type to `gen.mkAttributedCast`, which calls `gen.mkCast`)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
only trivial merge conflicts here.
not dealing with PR #4333 in this merge because there is a substantial
conflict there -- so that's why I stopped at
63daba33ae99471175e9d7b20792324615f5999b for now
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example usage:
trait =!=[C, D]
implicit def neq[E, F] : E =!= F = null
@annotation.implicitAmbiguous("Could not prove ${J} =!= ${J}")
implicit def neqAmbig1[G, H, J] : J =!= J = null
implicit def neqAmbig2[I] : I =!= I = null
implicitly[Int =!= Int]
Which gives the following error:
implicit-ambiguous.scala:9: error: Could not prove Int =!= Int
implicitly[Int =!= Int]
^
Better than what was previously given:
implicit-ambiguous.scala:9: error: ambiguous implicit values:
both method neqAmbig1 in object Test of type [G, H, J]=> Main.$anon.Test.=!=[J,J]
and method neqAmbig2 in object Test of type [I]=> Main.$anon.Test.=!=[I,I]
match expected type Main.$anon.Test.=!=[Int,Int]
implicitly[Int =!= Int]
^
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We add a static field to each class that defines lambdas that
will hold a `ju.Map[String, MethodHandle]` to cache references to
the constructors of the classes originally created by
`LambdaMetafactory`.
The cache is initially null, and created on the first deserialization.
In case of a race between two threads deserializing the first
lambda hosted by a class, the last one to finish will clobber
the one-element cache of the first.
This lack of strong guarantees mirrors the current policy in
`LambdaDeserializer`.
We should consider whether to strengthen the combinaed guarantee here.
A useful benchmark would be those of the invokedynamic instruction,
which allows multiple threads to call the boostrap method in parallel,
but guarantees that if that happens, the results of all but one will
be discarded:
> If several threads simultaneously execute the bootstrap method for
> the same dynamic call site, the Java Virtual Machine must choose
> one returned call site object and install it visibly to all threads.
We could meet this guarantee easily, albeit excessively, by
synchronizing `$deserializeLambda$`. But a more fine grained
approach is possible and desirable.
A test is included that shows we are able to garbage collect
classloaders of classes that have hosted lambda deserialization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support serialization, we use the alternative lambda metafactory
that lets us specify that our anonymous functions should extend the
marker interface `scala.Serializable`. They will also have a
`writeObject` method added that implements the serialization proxy
pattern using `j.l.invoke.SerializedLamba`.
To support deserialization, we synthesize a `$deserializeLamba$`
method in each class with lambdas. This will be called reflectively by
`SerializedLambda#readResolve`. This method in turn delegates to
`LambdaDeserializer`, currently defined [1] in `scala-java8-compat`,
that uses `LambdaMetafactory` to spin up the anonymous class and
instantiate it with the deserialized environment.
Note: `LambdaDeserializer` can reuses the anonymous class on subsequent
deserializations of a given lambda, in the same spirit as an
invokedynamic call site only spins up the class on the first time
it is run. But first we'll need to host a cache in a static field
of each lambda hosting class. This is noted as a TODO and a failing
test, and will be updated in the next commit.
`LambdaDeserializer` will be moved into our standard library in
the 2.12.x branch, where we can introduce dependencies on the
Java 8 standard library.
The enclosed test cases must be manually run with indylambda enabled.
Once we enable indylambda by default on 2.12.x, the test will
actually test the new feature.
```
% echo $INDYLAMBDA
-Ydelambdafy:method -Ybackend:GenBCode -target:jvm-1.8 -classpath .:scala-java8-compat_2.11-0.5.0-SNAPSHOT.jar
% qscala $INDYLAMBDA -e "println((() => 42).getClass)"
class Main$$anon$1$$Lambda$1/1183231938
% qscala $INDYLAMBDA -e "assert(classOf[scala.Serializable].isInstance(() => 42))"
% qscalac $INDYLAMBDA test/files/run/lambda-serialization.scala && qscala $INDYLAMBDA Test
```
This commit contains a few minor refactorings to the code that
generates the invokedynamic instruction to use more meaningful
names and to reuse Java signature generation code in ASM rather
than the DIY approach.
[1] https://github.com/scala/scala-java8-compat/pull/37
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These methods are "signature polymorphic", which means that compiler
should not:
1. adapt the arguments to `Object`
2. wrap the repeated parameters in an array
3. adapt the result type to `Object`, but instead treat it as it
it already conforms to the expected type.
Dispiritingly, my initial attempt to implement this touched the type
checker, uncurry, erasure, and the backend.
However, I realized we could centralize handling of this in the typer
if at each application we substituted the signature polymorphic
symbol with a clone that carried its implied signature, which is
derived from the types of the arguments (typechecked without an
expected type) and position within and enclosing cast or block.
The test case requires Java 7+ to compile so is currently embedded
in a conditionally compiled block of code in a run test.
We ought to create a partest category for modern JVMs so we can
write such tests in a more natural style.
Here's how this looks in bytecode. Note the `bipush` / `istore`
before/after the invocation of `invokeExact`, and the descriptor
`(LO$;I)I`.
```
% cat sandbox/poly-sig.scala && qscala Test && echo ':javap Test$#main' | qscala
import java.lang.invoke._
object O {
def bar(x: Int): Int = -x
}
object Test {
def main(args: Array[String]): Unit = {
def lookup(name: String, params: Array[Class[_]], ret: Class[_]) = {
val lookup = java.lang.invoke.MethodHandles.lookup
val mt = MethodType.methodType(ret, params)
lookup.findVirtual(O.getClass, name, mt)
}
def lookupBar = lookup("bar", Array(classOf[Int]), classOf[Int])
val barResult: Int = lookupBar.invokeExact(O, 42)
()
}
}
scala> :javap Test$#main
public void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=2
0: aload_0
1: invokespecial #18 // Method lookupBar$1:()Ljava/lang/invoke/MethodHandle;
4: getstatic #23 // Field O$.MODULE$:LO$;
7: bipush 42
9: invokevirtual #29 // Method java/lang/invoke/MethodHandle.invokeExact:(LO$;I)I
12: istore_2
13: return
LocalVariableTable:
Start Length Slot Name Signature
0 14 0 this LTest$;
0 14 1 args [Ljava/lang/String;
13 0 2 barResult I
LineNumberTable:
line 16: 0
}
```
I've run this test across our active JVMs:
```
% for v in 1.6 1.7 1.8; do java_use $v; pt --terse test/files/run/t7965.scala || break; done
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:02)
Test Run PASSED
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:07)
Test Run PASSED
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:05)
Test Run PASSED
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Playing with Java 8 Streams from the repl showed
we weren't eta-expanding, nor resolving overloading for SAMs.
Also, the way Java uses wildcards to represent use-site variance
stresses type inference past its bendiness point (due to excessive existentials).
I introduce `wildcardExtrapolation` to simplify the resulting types
(without losing precision): `wildcardExtrapolation(tp) =:= tp`.
For example, the `MethodType` given by `def bla(x: (_ >: String)): (_ <: Int)`
is both a subtype and a supertype of `def bla(x: String): Int`.
Translating http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/
into Scala shows most of this works, though we have some more work to do (see near the end).
```
scala> import java.util.Arrays
scala> import java.util.stream.Stream
scala> import java.util.stream.IntStream
scala> val myList = Arrays.asList("a1", "a2", "b1", "c2", "c1")
myList: java.util.List[String] = [a1, a2, b1, c2, c1]
scala> myList.stream.filter(_.startsWith("c")).map(_.toUpperCase).sorted.forEach(println)
C1
C2
scala> myList.stream.filter(_.startsWith("c")).map(_.toUpperCase).sorted
res8: java.util.stream.Stream[?0] = java.util.stream.SortedOps$OfRef@133e7789
scala> Arrays.asList("a1", "a2", "a3").stream.findFirst.ifPresent(println)
a1
scala> Stream.of("a1", "a2", "a3").findFirst.ifPresent(println)
a1
scala> IntStream.range(1, 4).forEach(println)
<console>:37: error: object creation impossible, since method accept in trait IntConsumer of type (x$1: Int)Unit is not defined
(Note that Int does not match Any: class Int in package scala is a subclass of class Any in package scala, but method parameter types must match exactly.)
IntStream.range(1, 4).forEach(println)
^
scala> IntStream.range(1, 4).forEach(println(_: Int)) // TODO: can we avoid this annotation?
1
2
3
scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println(_: Double))
5.0
scala> Stream.of("a1", "a2", "a3").map(_.substring(1)).mapToInt(_.parseInt).max.ifPresent(println(_: Int)) // whoops!
ReplGlobal.abort: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false
error: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false
scala.reflect.internal.FatalError: Unknown type: <error>, <error> [class scala.reflect.internal.Types$ErrorType$, class scala.reflect.internal.Types$ErrorType$] TypeRef? false
at scala.reflect.internal.Reporting$class.abort(Reporting.scala:59)
scala> IntStream.range(1, 4).mapToObj(i => "a" + i).forEach(println)
a1
a2
a3
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that I removed the check to ignore @deprecated:
- @deprecated extends StaticAnnotation, so they aren't
supposed to show up in the RuntimeInvisibleAnnotation
attribute anyway, and the earlier check for "extends
ClassfileAnnotationClass" makes this check superflous
anyway.
- Otherwise, if @deprecated was extending
ClassfileAnnotationClass it would seem inconsistent
that we don't emit @deprecated, but would do so for
@deprecatedOverriding, @deprecatedInheritance, etc.
Anyway, due to ClassfileAnnotation not working in
Scala, and the additional check which only allows
Java-defined annotations, this is pretty pointless
from every perspective.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just one of the possible strategies for compatibility with
reflection API of 2.10.x family. Here’s the discussion:
1) Do nothing.
Document the fact that we’ve organized internal APIs in a separate module
and let people figure out themselves.
Pros: no boilerplate on our side.
Cons: potential for confusion, major upfront migration effort.
2) (This commit). Introduce a compatibility pack with a manual import.
Compatibility pack lives in a separate module that has to be manually imported.
People will get compilation errors when trying to compile macros using
internal APIs against 2.11, but those will be quenched by a single
`import compat._` import. Compatibility stubs would still produce
deprecation warnings, but people can choose to ignore them to alleviate
migration costs.
Pros: brings attention of the users to the fact that they are using
internal APIs by providing a more powerful nudge than just deprecation.
Cons: even though migration effort is trivial, it is still non-zero.
3) Deprecate internal APIs in-place.
Pros: zero migration effort required.
Cons: those who ignore deprecations will be unaware about using internal APIs,
there will be some naming conflicts between Universe.xxxType and internal.xxxType
type factories.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out `findMembers` has been a bit sloppy in recent
years and has returned private members from *anywhere* up the
base class sequence. Access checks usually pick up the slack
and eliminate the unwanted privates.
But, in concert with the "concrete beats abstract" rule in
`findMember`, the following mishap appeared:
scala> :paste
// Entering paste mode (ctrl-D to finish)
trait T { def a: Int }
trait B { private def a: Int = 0 }
trait C extends T with B { a }
// Exiting paste mode, now interpreting.
<console>:9: error: method a in trait B cannot be accessed in C
trait C extends T with B { a }
^
I noticed this when compiling Akka against JDK 8; a new private method
in the bowels of the JDK was enough to break the build!
It turns out that some finesse in needed to interpret SLS 5.2:
> The private modifier can be used with any definition or declaration
> in a template. They are not inherited by subclasses [...]
So, can we simply exclude privates from all but the first base class?
No, as that might be a refinement class! The following must be
allowed:
trait A { private def foo = 0; trait T { self: A => this.foo } }
This commit:
- tracks when the walk up the base class sequence passes the
first non-refinement class, and excludes private members
- ... except, if we are at a direct parent of a refinement
class itself
- Makes a corresponding change to OverridingPairs, to only consider
private members if they are owned by the `base` Symbol under
consideration. We don't need to deal with the subtleties of
refinements there as that code is only used for bona-fide classes.
- replaces use of `hasTransOwner` when considering whether a
private[this] symbol is a member.
The last condition was not grounded in the spec at all. The change
is visible in cases like:
// Old
scala> trait A { private[this] val x = 0; class B extends A { this.x } }
<console>:7: error: value x in trait A cannot be accessed in A.this.B
trait A { private[this] val x = 0; class B extends A { this.x } }
^
// New
scala> trait A { private[this] val x = 0; class B extends A { this.x } }
<console>:8: error: value x is not a member of A.this.B
trait A { private[this] val x = 0; class B extends A { this.x } }
^
Furthermore, we no longer give a `private[this]` member a free pass
if it is sourced from the very first base class.
trait Cake extends Slice {
private[this] val bippy = ()
}
trait Slice { self: Cake =>
bippy // BCS: Cake, Slice, AnyRef, Any
}
The different handling between `private` and `private[this]`
still seems a bit dubious.
The spec says:
> An different form of qualification is private[this]. A member M
> marked with this modifier can be accessed only from within the
> object in which it is defined. That is, a selection p.M is only
> legal if the prefix is this or O.this, for some class O enclosing
> the reference. In addition, the restrictions for unqualified
> private apply.
This sounds like a question of access, not membership. If so, we
should admit `private[this]` members from parents of refined types
in `FindMember`.
AFAICT, not too much rests on the distinction: do we get a
"no such member", or "member foo inaccessible" error? I welcome
scrutinee of the checkfile of `neg/t7475f.scala` to help put
this last piece into the puzzle.
One more thing: findMember does not have *any* code the corresponds
to the last sentence of:
> SLS 5.2 The modifier can be qualified with an identifier C
> (e.g. private[C]) that must denote a class or package enclosing
> the definition. Members labeled with such a modifier are accessible
> respectively only from code inside the package C or only from code
> inside the class C and its companion module (§5.4).
> Such members are also inherited only from templates inside C.
When I showed Martin this, he suggested it was an error in the
spec, and we should leave the access checking to callers of
that inherited qualified-private member.
|
| |\
| |
| | |
SI-8131 fixes residual race condition in runtime reflection
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apparently some completers can call setInfo while they’re not yet done,
which resets the LOCKED flag, and makes anything that uses LOCKED to
track completion unreliable. Unfortunately, that’s exactly the mechanism
that was used by runtime reflection to elide locking for symbols that are
known to be initialized.
This commit fixes the problematic lock elision strategy by introducing
an explicit communication channel between SynchronizedSymbol’s and their
completers. Now instead of trying hard to infer whether it’s already
initialized or not, every symbol gets a volatile field that can be queried
to provide necessary information.
|
| | |
| |
| |
| |
| |
| | |
This reverts commit 000c18a8fac60065747652368dadcd7850532f3f,
because Symbol.isStable is independent from Type.isVolatile
since fada1ef6b315326ac0329d9e78951cfc95ad0eb0.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This makes it easy to differentiate unit inserted by a compiler vs unit
written by the user. Useful for quasiquotes and pretty printing.
Additionally SyntacticBlock extractor is changed to treat EmptyTree as
zero-element block.
|
| |\ \
| | |
| | | |
deprecates resetAllAttrs and resetLocalAttrs in favor of the new API
|
| | | |
| | |
| | |
| | |
| | | |
This cute little type is necessary for importers to work correctly.
I wonder how we could overlook its existence for almost 2 years.
|
| | | |
| | |
| | |
| | |
| | | |
As suggested by the reviewers, tostringXXX variables in TypeToStrings.scala
have been renamed to toStringXXX.
|
