Inner class constructors should use the argument instead of reading
outer `this` from a field because if such an access happens before a
delegating constructor call, e.g. when evaluating an argument, a JVM
bytecode validation error will be thrown. (The only operation on `this`
allowed before a delegating constructor call is SETFIELD, and only if
the field in question is declared in the same class.)
Move to subclasses: getJvmInternalClass, getJsInternalClass and
getKonanInternalClass (in Kotlin/Native). The advantage of this is that
this API need not be shared between backends any longer, which makes
sense because implementation details differ across platforms
Same problem as in deafult argument lowering: JVM and JS semantics differ.
Same solution: skip in common lowerings, process if needed in platform ones.
* commit 575cbf48c3
| Author: SvyatoslavScherbina <Svyatoslav.Scherbina@jetbrains.com>
| Date: Thu Mar 14 14:25:10 2019 +0300
|
| Optimize DescriptorReferenceDeserializer again (#2755)
to common ir deserializer.
This however makes testLocalFunctionName fail because currently
isSubclassOf (incorrectly) returns false and therefore an anonymous
class is generated and the name is taken from there. The name there is
"box$OK" which is incorrect. The isSubclassOf issue is KT-28198 and will
be fixed separately; the incorrect name issue will be investigated later
Consolidating these into IrStringConcatenations allows the backend to produce efficient code for string concatenations (e.g., using StringBuilder for JVM).
Introduce MetadataSource as a way to store the original descriptor for
any element (before any lowerings) and maintain it until the end of the
codegen where it's used in generating the metadata. Note that JVM
signatures written to the metadata are formed from the _resulting_
generated elements, not by mapping the original descriptors.
Some corner cases are not supported yet, namely properties declared in
companion objects, synthetic methods for property annotations,
JvmPackageName, etc.
#KT-29119 Fixed
In InnerClassesLowering, the type of the "outer$0" expression should be
the outer class, not the inner class. In EnumClassLowering, the type of
the enum entry is the type of its class or the type of the enum class,
but not the type of initialierExpression which is always Unit
Dmitry Petrov