| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| | |
Fix some typos (a-c)
|
| | |
| |
| |
| |
| |
| | |
I just used text search to check whether there are no more typos like
these corrected by janekdb, and by the way fixed also some other ones
which I saw.
|
| | | |
|
| |\ \
| |/
|/| |
Fix illegal inlining of instructions accessing protected members
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were two issues in the new inliner that would cause a
VerifyError and an IllegalAccessError.
First, an access to a public member of package protected class C can
only be inlined if the destination class can access C. This is tested
by t7582b.
Second, an access to a protected member requires the receiver object
to be a subtype of the class where the instruction is located. So
when inlining such an access, we need to know the type of the receiver
object - which we don't have. Therefore we don't inline in this case
for now. This can be fixed once we have a type propagation analyis.
https://github.com/scala-opt/scala/issues/13.
This case is tested by t2106.
Force kmpSliceSearch test to delambdafy:inline
See discussion on https://github.com/scala/scala/pull/4505. The issue
will go away when moving to indy-lambda.
|
| |\ \
| | |
| | | |
SI-9356 more careful assertion in back-end
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Calling `exists` on a `Symbol` triggers unpickling,
which failed for reasons I did not investigate.
Replaced `sym.exists` by `sym != NoSymbol`, which is good enough here.
Also replaced assertion by a `devWarning`, since the
logic seems too ad-hoc to actually crash the compiler when it's invalidated.
Partially reverts b45a91fe22. See also #1532.
|
| |\ \ \
| | | |
| | | | |
SI-9348 Fix missing last element in exclusive floating point ranges
|
| | |/ /
| | |
| | |
| | |
| | | |
Fix exclusive floating point ranges to contain also the last element
when the end-start difference is not an integer multiple of step.
|
| |\ \ \
| |/ /
|/| | |
Fix toolbox with varargs constructors
|
| | | |
| | |
| | |
| | | |
It was already working for methods, but not for constructors.
|
| |\ \ \
| |/ /
|/| | |
SI-7747 Make REPL wrappers serialization friendly.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We only need to introduce the temporary val in the imports
wrapper when we are importing a val or module defined in the REPL.
The test case from the previous commit still passes, but
we are generating slightly simpler code.
Compared to 2.11.6, these two commits result in the following
diff:
https://gist.github.com/retronym/aa4bd3aeef1ab1b85fe9
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Spark has been shipping a forked version of our REPL for
sometime. We have been trying to fold the patches back into
the mainline so they can defork. This is the last outstanding
issue.
Consider this REPL session:
```
scala> val x = StdIn.readInt
scala> class A(a: Int)
scala> serializedAndExecuteRemotely {
() => new A(x)
}
```
As shown by the enclosed test, the REPL, even with the
Spark friendly option `-Yrepl-class-based`, will re-initialize
`x` on the remote system.
This test simulates this by running a REPL session, and then
deserializing the resulting closure into a fresh classloader
based on the class files generated by that session. Before this
patch, it printed "evaluating x" twice.
This is based on the Spark change described:
https://github.com/mesos/spark/pull/535#discussion_r3541925
A followup commit will avoid the `val lineN$read = ` part if we
import classes or type aliases only.
[Original commit from Prashant Sharma, test case from Jason Zaugg]
|
| |\ \ \
| | | |
| | | | |
Nullness Analysis for GenBCode
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
When inlining an instance call, the inliner has to ensure that a NPE
is still thrown if the receiver object is null. By using the nullness
analysis, we can avoid emitting this code in case the receiver object
is known to be not-null.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
-Xlint:stars-align warns only if elementarity > 0, that is,
if an extracted sequence is not matched entirely by a pattern
sequence, that is, in SLS 8.1.9 on pattern sequences, n = 1
and that pattern is a pattern sequence.
This is still only triggered if productarity > 0, that is,
a non-pattern-sequence pattern is required for the match.
This is a sensitive area because it borders on exhaustiveness
checking: it would be preferable to verify just that the match
is exhaustive, and to emit this warning only if it is not.
|
| |\ \ \
| | | |
| | | | |
Fix several tests under GenBCode
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Recently, in 029cce7, I changed uncurry to selectively fallback
to the old method of emitting lambdas when we detect that
`-Ydelambdafy:method`.
The change in classfile names breaks the expectations of
the test `innerClassAttribute`.
This commit changes that test to avoid using specialized
functions, so that under -Ydelambdafy:method all functions
are uniform. This changes a few fresh suffixes for anonymous
class names under both `-Ydelambdafy:{inline,method}`, so the
expectations have been duly updated.
Similarly, I have changed `javaReflection` in the same manner.
Its checkfiles remained unchanged.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- private-inline, t8601-closure-elim, inline-in-constructors
- test closure inlining / elimination, which is not yet implemented
in GenBCode. noted in https://github.com/scala-opt/scala/issues/14.
- constant-optimization, t7006
- no constant folding in GenBCode yet.
noted in https://github.com/scala-opt/scala/issues/29.
- patmat_opt_ignore_underscore, patmat_opt_no_nullcheck, patmat_opt_primitive_typetest
- not all optimizations in GenBCode yet.
noted in https://github.com/scala-opt/scala/issues/30.
- t3234
- tests a warning of trait inlining - trait inlining works in
GenBCode
- synchronized
- ignore inliner warnings (they changed a bit)
- t6102
- account for the changed outputo of -Ydebug has under GenBCode
|
| |\ \ \
| |/ /
|/| | |
SI-9321 Clarify spec for inheritance of qualified private
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I checked the intent with Martin, who said:
> [...] qualified private members are inherited like other members,
> it’s just that their access is restricted.
I've locked this in with a test as well.
|
| |\ \ \
| | | |
| | | | |
SI-9286 Check subclass privates for "same type after erasure"
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The overriding pairs cursor used to detect erased signature clashes
was turning a blind eye to any pair that contained a private method.
However, this could lead to a `VerifyError` or `IllegalAccessError`.
Checking against javac's behaviour in both directions:
```
% cat sandbox/Test.java
public abstract class Test {
class C { int foo() { return 0; } }
class D extends C { private <A> int foo() { return 1; } }
}
% javac sandbox/Test.java
sandbox/Test.java:3: error: name clash: <A>foo() in Test.D and foo() in Test.C have the same erasure, yet neither overrides the other
class D extends C { private <A> int foo() { return 1; } }
^
where A is a type-variable:
A extends Object declared in method <A>foo()
1 error
```
```
% cat sandbox/Test.java
public abstract class Test {
class C { private int foo() { return 0; } }
class D extends C { <A> int foo() { return 1; } }
}
% javac sandbox/Test.java
%
```
This commit only the exludes private symbols from the superclass
from the checks by moving the test from `excludes` to `matches`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`LambdaMetafactory` generates code to perform a limited number
of type adaptations when delegating from its implementation of
the functional interface method to the lambda target method.
These adaptations are: numeric widening, casting, boxing and unboxing.
However, the semantics of unboxing numerics in Java differs to Scala:
they treat `UNBOX(null)` as cause to raise a `NullPointerException`,
Scala (in `BoxesRuntime.unboxTo{Byte,Short,...}`) reinterprets the
null as zero.
Furthermore, Java has no idea how to adapt between a value class and
its wrapped type, nor from a void return to `BoxedUnit`.
This commit detects when the lambda target method would require
such adaptation. If it does, an extra method, `$anonfun$1$adapted` is
created to perform the adaptation, and this is used as the target
of the lambda.
This obviates the use of `JProcedureN` for `Unit` returning
lambdas, we know use `JFunctionN` as the functional interface
and bind this to an `$adapted` method that summons the instance
of `BoxedUnit` after calling the `void` returning lambda target.
The enclosed test cases fail without boxing changes. They don't
execute with indylambda enabled under regular partest runs yet,
you need to add scala-java8-compat to scala-library and pass
the SCALAC_OPTS to partest manually to try this out, as described
in https://github.com/scala/scala/pull/4463. Once we enable indylambda
by default, however, this test will exercise the code in this patch
all the time.
It is also possible to run the tests with:
```
% curl https://oss.sonatype.org/content/repositories/releases/org/scala-lang/modules/scala-java8-compat_2.11/0.4.0/scala-java8-compat_2.11-0.4.0.jar > scala-java8-compat_2.11-0.4.0.jar
% export INDYLAMBDA="-Ydelambdafy:method -Ybackend:GenBCode -target:jvm-1.8 -classpath .:scala-java8-compat_2.11-0.4.0.jar"
qscalac $INDYLAMBDA test/files/run/indylambda-boxing/*.scala && qscala $INDYLAMBDA Test
```
|
| |/
|
|
|
|
|
|
|
|
| |
The tagged revisions of the modules integrate the latest release of
the sbt-scala-modules sbt plugin. This enables building with a new
scala binary version (e.g. 2.12.0-M1) without failinig MiMa.
Also updates the other external dependencies.
Backport of 8da073cd6bfaaaf3789fc8b70a61ebb66a2f0ded
|
| |
|
|
|
|
|
|
|
|
| |
Previously, the flag caused any elidable to be elided.
This commit simply sets -Xelide-below to ASSERTION + 1.
The flag is useful because there's no mnemonic for specifying
the magic constant as an option argument. `-Xelide-below ASSERTION`
means asserts are enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Value classes that appear in signatures of Java defined methods
should not be erased to the underlying type.
Before this change, we'd get a `ClassCastException`, as the Scala
call site would unbox the value class despite the fact the Java
recipient would expect the boxed representation.
I've tested this for primitive and object wrapped types in parameter
and return position.
|
| |\
| |
| | |
Remove references to the old PDF version of the specification
|
| | | |
|
| |\ \
| | |
| | | |
SI-8679 Add support for ScalaLongSignature attribute in scalap
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
scalap didn't support really big class files. It was returning an
empty String for such files. The reason was that there were only
ScalaSignatures taken into account.
This commit adds support for ScalaLongSignature. We try to get such
an attribute when we didn't find ScalaSignature. Also there's added
an additional case to the logic retrieving bytes for a signature.
Since ScalaLongSignature can contain many parts, we have to merge
their byte arrays.
Changes are tested by a new partest-based test. These two files are
really big, but it was required (t8679.scala is a reduced version of
BigScalaClass - an example attached to JIRA).
There are also added TODOs with a JIRA ticket: We have three places,
where we process Scala signatures. In the future it would be better to
reuse some common logic, if it's possible.
|
| |\ \ \
| | | |
| | | | |
Use LambdaMetafactory where possible for lambda creation.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
SI-9285 Don't warn about non-sensible equals in synthetic methods
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
Notably, in the synthetic equals method of a case class. Otherwise,
we get an unsuppressable warning when defining a case class with a
`Unit`-typed parameter, which some folks use a placeholder for
real type while evolving a design.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | | |
Fix many typos
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This commit corrects many typos found in scaladocs and comments.
There's also fixed the name of a private method in ICodeCheckers.
|
| |\ \ \ \
| |/ / /
|/| | | |
Don't crash GenBCode for value classes with a self declaration
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If a value class has a self declaration
class V(x: Long) extends AnyVal { self => /* ... */ }
`vClassSymbol.typeOfThis.typeSymbol` is `class Long` in the backend.
The InlineInfo for traits contains a field for the self type of the
trait. This is required for re-writing calls to final trait methods
to the static implementation method: the self type appears in the
impl method signature.
By mistake, the backend was recording the self type of all classes,
not only of traits. In the case of a value class with a self
declaration, this broke the assumption that the self type is always
a class type (not a primitive type).
The simple fix: only record the self type for traits.
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When parsing a Java generic signature that references an inner
class `A$B`, we were tripping an assertion if the enclosing class
`A` was absent.
This commit creates a stub symbol for `B` when this happens, rather
than continuing on with `NoSymbol`.
The enclosed test shows that we can instantiate a class containing
a method referring to such an inner class with only a warning
about the absent classfile, and that an error is issued only upon
a subsequent attempt to call the method.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Under -Ydelambdafy:method (the basis of the upcoming "indylambda"
translation for -target:jvm-1.8), an anonymous function is currently
encoded as:
1. a private method containing the lambda's code
2. a public, static accessor method that allows access to 1 from
other classes, namely:
3. an anonymous class capturing free variables and implementing
the suitable FunctionN interface.
In our prototypes of indylambda, we do away with 3, instead deferring
creating of this class to JDK8's LambdaMetafactory by way of an
invokedynamic instruction at the point of lambda capture. This
facility can use a private method as the lambda target; access is
mediated by the runtime-provided instance of
`java.lang.invoke.MethodHandles.Lookup` that confers the privelages
of the lambda capture call site to the generated implementation class.
Indeed, The java compiler uses this to emit private lambda body
methods.
However, there are two Scala specific factors that make this
a little troublesome.
First, Scala's optimizer may want to inline the lambda capture
call site into a new enclosing class. In general, this isn't a
safe optimization, as `invokedynamic` instructions have call-site
specific semantics. But we will rely the ability to inline like
this in order to eliminate closures altogether where possible.
Second, to support lambda deserialization, the Java compiler creates
a synthetic method `$dersializeLamda$` in each class that captures
them, just to be able to get the suitable access to spin up an
anoymous class with access to the private method. It only needs
to do this for functional interfaces that extends Serializable,
which is the exception rather than the rule. But in Scala, *every*
function must support serialization, so blindly copying the Java
approach will lead to some code bloat.
I have prototyped a hybrid approach to these challenges: use the
private method directly where it is allowed, but fall back to
using the accessor method in a generic lambda deserializer or
in call sites that have been inlined into a new enclosing class.
However, the most straight forward approach is to simply emit the
lambda bodies as public (with an mangled name and with the SYHTNETIC
flag) and use them in all cases. That is what is done in this commit.
This does moves us one step backwards from the goals of SI-7085,
but it doesn't seem sensible to incur the inconvenience from locking
down one small part of our house when we don't have a plan or the
budget to complete that job.
The REPL has some fancy logic to decompile the bodys of lambdas
(`:javap -fun C#m`) which needed tweaking to accomodate this change.
I haven't tried to make this backwards compatible with the old
encoding as `-Ydelambdafy:method` is still experimental.
|
| |\ \ \
| |/ /
|/| | |
SI-3368 Default to coalescing for 2.11
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Preserve current behavior (no PCData nodes, only Text)
for 2.11.
The coalescing flag is on if enabled or if source level
is not 2.12 and no flag was supplied.
The subtle change is that adjacent Text nodes are thereby
coalesced. This happens in the presence of CData sections,
but this is at the discretion of the parser anyway.
Also, no PCData nodes are emitted under coalescing, even
if there were no sibling text nodes. That is the correct
behavior: the general idea is that coalescing mode says,
I only want to deal with text.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A bare identifier `classOf` in a position wth an expected type of
`Class[_]` was leading to an unpositioned error.
This is due to special treatment of bare `classOf` in `typedIdent`
creating an ephemeral, but unpositioned, `TypeTree`.
This commit positions that tree and tests that the error is
issued at a sensible position.
There is still an irregularity between `classOf` and `Predef.classOf`,
but that seems esoteric enough to leave alone for now.
|
