Before this change, we stored the enclosing constructor in a map in
JvmBackendContext before moving lambdas and local classes out of
initializer blocks. However, in case the lambda was declared in an inner
class, we stored a reference to the unlowered constructor of the inner
class, whose JVM signature is "()V" instead of the correct "(LOuter;)V".
Java reflection then threw exception if we tried to call
`getEnclosingConstructor()` on such class at runtime. Proguard finished
with errors for the same reason.
It turns out that we can just store the fact that the class has been
moved, and load the matching constructor in codegen, where everything is
already lowered and guaranteed to match with the signatures of the
actual generated declarations.
#KT-41668 Fixed
There was a typo in JvmLocalClassPopupLowering which allowed the
EnclosingMethod for lambdas and anonymous classes in initializers to
become any function in a class, in case when there was no primary
constructor in that class. E.g. in the added test, `getIrrelevantField`
was the EnclosingMethod of the lambda class before this change.
In box tests, only check that Java reflection does not crash on the
EnclosingMethod attribute generated in these classes. If it doesn't
crash, most likely it returns the value that can be read from the class
file by ASM, which is what the newly added bytecode listing tests are
checking now.
Raw type Q is represented as a flexible type
Q<B1, ... Bn> .. Q<*, ... *>
where Bi is a representative upper bound of the corresponding ith type
parameter of Q.
When mapping generic signature, JVM takes type arguments of lower bound
(which is 'Q<B1, ..., Bn>').
There is still some difference in how JVM and JVM_IR handle raw type in
signature. It requires additional investigation.
Before this change, we incorrectly mangled the names of annotation
methods (e.g. `getI-pVg5ArA` instead of `i`) because the isSpecial
condition was false.
NB some cases such as captured extension receiver for an extension
lambda are not supported yet; to be discussed, to what extent should we
actually follow JVM code shape here.
1. Enum entry fields don't have nullability annotations.
2. Enum class special methods (values, valueOf) are not 'final'
(although they probably should be, javac generates corresponding
methods without ACC_FINAL flag).
3. Enum class special methods don't have nullability annotations.
4. Don't generate synthetic accessor for enum entry class constructor.
KT-37019 KT-37020 KT-37021
Alexander Udalov