| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Scala classfile and java source parsers make Java annotation
classes (which are actually interfaces at the classfile level) look
like Scala annotation classes:
- the INTERFACE / ABSTRACT flags are not added
- scala.annotation.Annotation is added as superclass
- scala.annotation.ClassfileAnnotation is added as interface
This makes type-checking @Annot uniform, whether it is defined in Java
or Scala.
This is a hack that leads to various bugs (SI-9393, SI-9400). Instead
the type-checking should be special-cased for Java annotations.
This commit fixes SI-9393 and a part of SI-9400, but it's still easy
to generate invalid classfiles. Restores the assertions that were
disabled in #4621. I'd like to leave these assertions in: they
are valuable and helped uncovering the issue being fixed here.
A new flag JAVA_ANNOTATION is introduced for Java annotation
ClassSymbols, similar to the existing ENUM flag. When building
ClassBTypes for Java annotations, the flags, superclass and interfaces
are recovered to represent the situation in the classfile.
Cleans up and documents the flags space in the area of "late" and
"anti" flags.
The test for SI-9393 is extended to test both the classfile and the
java source parser.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move run/t8960 to pending
It tests the serialVersionUID field on closure classes. The field
doesn't exist for indyLambda closures.
See https://issues.scala-lang.org/browse/SI-9373
Move some reify tests to pending
They fail at runtime in GenBCode since scala is built with indyLambda
enabled:
java.lang.AssertionError: assertion failed: Bad superClass for trait JFunction1: class Any
at scala.tools.nsc.Global.assert(Global.scala:261)
at scala.tools.nsc.backend.jvm.BTypesFromSymbols.setClassInfo(BTypesFromSymbols.scala:228)
Noted in https://issues.scala-lang.org/browse/SI-9374
force t6546 to GenASM - no closure elimination in GenBCode yet
Noted in https://issues.scala-lang.org/browse/SI-9364.
Fix or disable some tests that fail because of the old optimizer
The old inliner fails more often when the library is built with
indylambda.
Noted in https://issues.scala-lang.org/browse/SI-9374.
Example: List.foreach
➜ sandbox git:(jfun) ✗ qs -Ybackend:GenASM -optimize -Yinline-warnings
Welcome to Scala version 2.12.0-20150630-220939-1cb032d806 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45).
Type in expressions to have them evaluated.
Type :help for more information.
scala> List(1,2,3).foreach(x => x + 1)
<console>:11: warning: Could not inline required method foreach because bytecode unavailable.
List(1,2,3).foreach(x => x + 1)
^
<console>:11: warning: At the end of the day, could not inline @inline-marked method foreach
List(1,2,3).foreach(x => x + 1)
^
Upate a number of tests for having indyLambda enabled
The delambdafyLambdaClassNames tests was removed, there's nothing to
tests with indyLambda.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Members of value classes are moved over to the companion object early.
This change ensures that closure classes nested in value classes
appear that way to Java reflection.
This commit also changes the EnclosingMethod attribute for classes
(and anonymous functions) nested in anonymous function bodies. Before,
the enclosing method was in some cases the function's apply method.
Not always though:
() => { class C ... val a = { class D ...} }
The class C used to be nested in the function's apply method, but not
D, because the value definition for a was lifted out of the apply.
After this commit, we uniformly set the enclosing method of classes
nested in function bodies to `null`. This is consistent with the
source-level view of the code.
Note that under delambdafy:method, closures never appear as enclosing
classes (this didn't change in this commit).
|
| |
|
|
|
|
|
|
|
|
| |
Trait implementation classes and specialized classes are always
considered top-level in terms of the InnerClass / EnclosingMethod
attributes. These attributes describe source-level properties, and
such classes are a compilation artifact.
Note that the same is true for delambdafy:method closure classes
(they are always top-level).
|
| |
|
|
|
|
|
|
|
|
| |
Private trait methods are not added to the generated interface, they
end up only in the implementation class. For classes nested in such
methods, the EnclosingMethod attribute was incorrect.
Since the EnclosingMethod attribute expresses a source-level property,
but the actual enclosing method does not exist in the bytecode, we
set the enclosing method to null.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes both GenASM and GenBCode, except for the change
to renaming in LamdaLift mentioned below.
The reason for an inconsistent EnclosingMethod attribute was the
symbol owner chain. Initially, closure class symbols don't exist, they
are only created in UnCurry (delambdafy:inline). So walking the
originalOwner of a definition does not yield closure classes.
The commit also fixes uses of isAnonymousClass, isAnonymousFunction
and isDelambdafyFunction in two ways:
1. by phase-travelling to an early phase. after flatten, the name
includes the name of outer classes, so the properties may become
accidentally true (they check for a substring in the name)
2. by ensuring that the (destructive) renames during LambdaLift
don't make the above properties accidentally true. This was in
fact the cause for SI-8900.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This infrastructure is required for the inliner: when inlining code
from a classfile, the corresponding ClassBType is needed for various
things (eg access checks, InnerClass attribute).
The test creates two ClassBTypes for the same class: once using the
(unpickled) Symbol, once using the parsed ASM ClassNode, and verifies
that the two are the same.
There's a cleanup to the InnerClass attribute:
object T { class Member; def foo = { class Local } }
class T
For Java compatibility the InnerClass entry for Member says the class
is nested in T (not in the module class T$). We now make sure to add
that entry only to T, not to T$ (unless Member is actually referenced
in the classfile T$, in that case it will be added, as required).
|
| |
|
|
| |
This should have been done in 63207e1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit seems bigger than it is. Most of it is tests, and moving
some code around. The actual changes are small, but a bit subtle.
The InnerClass and EnclosingMethod attributes should now be close to
the JVM spec (which is summarized in BTypes.scala). New tests make
sure that changes to these attributes, and changes to the way Java
reflection sees Scala classfiles, don't go unnoticed.
A new file, BCodeAsmCommon, holds code that's shared between the two
backend (it could hold more, future work).
In general, the difficulty with emitting InnerClass / EnclosingMethod
is that we need to find out source-level properties. We need to make
sure to do enough phase-travelling, and work around destructive
changes to the ownerchain in lambdalift (we use originalOwner a lot).
The change to JavaMirrors is prompted by the change to the
EnclosingMethod attribute, which changes Java reflection's answer to
getEnclosingMethod and getEnclosingConstructor. Classes defined in
field initializers no longer have an enclosing method, just an
enclosing class, which broke an assumption in JavaMirrors.
There's one change in erasure. Before this change, when an object
declaration implements / overrides a method, and a bridge is required,
then the bridge method was actually a ModuleSymbol (it would get the
lateMETHOD flag and be emitted as a method anyway). This is confusing,
when iterating through the members of a class, you can find two
modules with the same name, and one of them doesn't have a module
class. Now, such bridge methods will be MethodSymbols.
Removed Symbol.originalEnclosingMethod, that is a backend thing and
doesn't need to live in the symbol API.
|
|
|
Some parts of the test assert (current) buggy behavior. This is marked
in the test file with TODO. It will be fixed in later work on the
backend.
|
