The JVM and newer Android runtimes treats that the same as if
there is no enclosing method. However, older Android runtimes
for Android 5 and 6 throw exceptions on reflective access
and even older runtimes have different behavior. To avoid
those issues, exclude <clinit> from enclosing method attributes.
^ KT-48754 Fixed
val y = 1
object { val x = y }
->
class XKt$1(`$y`: Int) { val x: Int = `$y` }
Note that `$y` is not stored in a field because it's not used outside
the primary constructor.
One exception is captured inline parameters on the JVM backend, as the
bytecode inliner uses field assignment instructions (setfield) to locate
them; removing the field is thus not possible.
Generate $delegate method as instance method in
PropertyReferenceDelegationLowering, and remove dispatch receiver later
in MakePropertyDelegateMethodsStatic. The method needs to be static to
be non-overridable (see delegateMethodIsNonOverridable.kt), and public
to be accessible in reflection.
Otherwise we generated incorrect IR where a static function accessed an
instance field of the containing class, which failed in multiple places
including LocalDeclarationsLowering.
#KT-48350 Fixed
The problem in the test case was that `JImpl.entrySet` was detected by
ReplaceDefaultImplsOverriddenSymbols as a class fake override, which
overrides non-abstract interface method. Thus, overriddenSymbols of
`MyMap.entrySet` were changed in
`ReplaceDefaultImplsOverriddenSymbols.visitSimpleFunction`.
Later, BridgeLowering tried to determine which special bridges to
generate for `MyMap.<get-entries>`, and for that it inspected existing
methods and their overrides.
Normally we would generate the following special bridge:
getEntries()Ljava/util/Set;
invokespecial JImpl.entrySet()Ljava/util/Set;
However, because of incorrect overrides, the generated class method was
selected here instead of the expected `Map.<get-entries>`:
https://github.com/JetBrains/kotlin/blob/06001fc0919c814e757caa494891619882fae15f/compiler/ir/backend.jvm/src/org/jetbrains/kotlin/backend/jvm/lower/BridgeLowering.kt#L282
and since the JVM signature of the generated class method is the same as
that of the fake override in MyMap, we never got to generating the
special bridge.
The solution is to skip Java classes when looking for class methods
which override non-abstract interface methods. This logic only makes
sense for Kotlin code, because only Kotlin has DefaultImpls, and the
requirement to generate non-abstract fake overrides of interface methods
as actual methods in the bytecode, delegating to DefaultImpls.
#KT-48167 Fixed
Seperate checker for platforms that do not support this language feature yet
Synthetic implementations of annotations are generated on-demand with proper
equals, hashCode, and annotationType methods
#KT-47699 Fixed
Note that resulting SAM method
public final method accept(p0: java.lang.Object): void
has a signature less specific than the resulting bridge method
public synthetic bridge method accept(p0: X): void
This is needed for the inliner: since the information about Kotlin type
of the bound receiver is nowhere in the output binary, the inliner will
have no clue how to box inline class values. Moving the boxing outside
the object means the inliner doesn't need to know about it; from its
point of view, the captured value has type `Any`.
For subclasses of `AbstractMutableList<Int>` which are not inline
classes, the special bridge `remove` had a parameter of type `Int`
(mapped to JVM primitive int) before this fix. The hack in
`MethodSignatureMapper` changed this type to `Int?`, yet the body of the
special bridge still loaded it as non-nullable, which resulted in
incorrect bytecode.
It looks like a part of this hack in `BridgeLowering` was made only for
inline classes which are subclasses of mutable collections. Supposedly
it should be extended to non-inline classes, so that `remove` special
bridge would have consistent IR by the time it reaches codegen.
#KT-46516 Fixed
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
Dmitry Petrov