collectPotentiallyCapturedTypeParameters no longer stops on the first
class when going through parents. This is needed because otherwise type
parameters of the containing class, and its outer classes, were never
considered "captured", and thus not duplicated/remapped later in
LocalDeclarationsLowering.
This led to the IR where a local function referenced generic type
parameters of the outer class. On JVM, local function is generated into
a private static function in that container class, and static functions
can't use generic type parameters, which crashed some bytecode
processing tools.
Also, add another explicit call to `seeType` to cover references to
generic type parameters in function return types.
#KT-45941 Fixed
Also, do not try to use invokedynamic on SAM calls with intersection
types, because intersection type is not allowed as an immediate type
projection of a supertype, and constructing a fake override in
LambdaMetafactoryArgumentsBuilder led to an exception. This fixes the
problem which was worked around earlier in e6c089ef, effectively
reverting that commit.
The main motivation for this change is that LambdaMetafactory also
doesn't generate generic signature for SAM wrapper classes at runtime.
Since these classes are synthetic, nobody should rely on the fact that
they have generic supertypes, which was observable only via Java
reflection.
#KT-46149 Fixed
#KT-46238 Fixed
Corresponding delegates are initialized in the host class, using
'$$delegatedProperties'.
TODO figure out proper code generation scheme for delegated properties
in companions (KT-45580)
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
Super-qualifiers have to be taken into account. Otherwise, too
few accessibility bridges will be generated which can lead to
binary compatibility issues.
This change improves the debugging experience around local functions
on the IR backend. The changes include moving old
checkLocalVariablesTable (cLVT) tests to the new stepping/local variable
infrastructure in order to refine the tests and further define the
behavior of the two JVM backends, and their differences.
The primary ported test case is cLVT/localFun.kt that documents the
discrepancy in implementation strategy for local functions on the two
backends. The old backend implements local functions as lambdas
assigned to a local variable while the IR backend lifts them out as
static funtions on the surrounding class. The discrepancies and their
consequences are documented in bytecodeListing, idea-stepping,
localVariableTable and debugStepping tests.
The only _code change_ is disabling the captured variable name
mangling for captured variables on the IR backend. Captured variables
are passed as arguments to the static function, so in the debugger,
they really just are local variables. For them to show properly in the
debugger and be detectable by evaluate expression, they simply need no
mangling.
Finally, this change cleans 3 redundant cLVT tests, copyFunction.kt
and destructuringInlineLambda.kt and destructuringInFor.kt, that are
all covered in the new suite. The stepping behavior needs to be made
precise around for loops, but that is an entirely seperate issue.
Alexander Udalov