Commonize (in terms of TypeSystemCommonBackendContext implementations
for KotlinType/IrType) code that computes optimal TypeMappingMode to
apply to different positions where inline class types can be present.
KotlinTypeMapper.mapInlineClassTypeAsDeclaration and
mapUnderlyingTypeOfInlineClassType invoked mapType which is defined in
descriptorBasedTypeSignatureMapping.kt and works on KotlinType.
It didn't lead to any problems, other than the fact that we were
constructing IrBasedClassDescriptor in JVM IR, and then KotlinType to
pass it to mapType, on each call to StackValue.boxInlineClass or
unboxInlineClass, which seems wasteful.
Instead of this, refactor these utilities to use type markers instead,
pass IrType and IrTypeMapper directly from JVM IR, and move the "static
type mapper" logic (which is used only in the old backend) out of
KotlinTypeMapper.
When a suspension point is inlined, the inlining local spans
unspilling code where the local slot has not been initialized.
The transformer already inserted initialization code for the local,
however, it did not split the local variable table. Therefore,
the inlining local is defined on instructions where the local
slot has no value (namely the instructions that initialize
the local slot on the unspilling path).
This change adds splitting of the local variable table as well.
When updating to a new version of D8, the uninitialized local
slot showed up. D8 will repair it in this case, but it is
better to not generate such code.
Pass parentContext to SamWrapperCodegen from the outside instead of
using the one from parentCodegen. The difference is that in case of an
inline lambda, we're creating an InlineLambdaContext whose parent is a
ClosureContext, but the codegen for that lambda has that latter
ClosureContext as its context. So the getNonInlineOuterContext call in
SamWrapperCodegen.generateInnerClassInformation wasn't able to identify
that this is a context of a lambda that needs to be skipped, and
generated it as EnclosingMethod, which caused Java reflection to fail
because once that lambda was inlined, it was removed and thus didn't
make it to runtime.
#KT-44827 Fixed
These utilties are used not only within CFG, but from the frontend and
idea as well. Therefore upon extraction of CFG into another module,
these two new files will remain in 'frontend'.
Improve the test which checks that we use correct metadata version if
`-language-version` is passed by checking all supported language
versions.
The change in libraries/reflect/build.gradle.kts is needed because
kotlinx-metadata-jvm of version 0.1.0 is based on pre-1.4 Kotlin, which
doesn't support the new module file metadata generated with metadata
version 1.4 and later, and module files need to be readable there to be
able to transform them for the shadow plugin.
Similarly override dependency on kotlinx-metadata-jvm in the
binary-compatibility-validator module.
In the old backend, this was unnecessary because nested objects would
reference their lambdas' captures through the original this$0. On
JVM_IR, using loose capture fields means a name/descriptor clash can
occur on any level of nesting, not just the top.
Alexander Udalov