summaryrefslogtreecommitdiff
path: root/test/files/jvm/innerClassAttribute/Test.scala
Commit message (Collapse)AuthorAgeFilesLines
* Fix InnerClass / EnclosingMethod for closures nested in value classesLukas Rytz2015-02-071-7/+62
| | | | | | | | | | | | | | | | | | | | | 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).
* Fix InnerClass/EnclosingMethod for trait impl and specialized classesLukas Rytz2015-02-071-2/+87
| | | | | | | | | | 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).
* SI-9124 fix EnclosingMethod of classes nested in implOnly trait defsLukas Rytz2015-02-071-0/+31
| | | | | | | | | | 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.
* SI-9105 Fix EnclosingMethod for classes defined in lambdasLukas Rytz2015-02-071-4/+74
| | | | | | | | | | | | | | | | | | | | | 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.
* Construct ClassBTypes from parsed classfilesLukas Rytz2015-01-161-15/+14
| | | | | | | | | | | | | | | | | | | | 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).
* Fix lambda names under delambdafy:method in innerClassAttribute testLukas Rytz2014-10-101-3/+3
| | | | This should have been done in 63207e1
* Fix InnerClass / EnclosingMethod attributesLukas Rytz2014-09-011-37/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* test for InnerClass and EnclosingMethod attributesLukas Rytz2014-08-121-0/+208
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.