The main idea of this refactoring is to separate two usages of
`AnnotationDeserializer.resolveValue`: the one where we load annotation
argument values, and the one where we load constant values of properties
for JS/Native/Common
(`AnnotationAndConstantLoaderImpl.loadPropertyConstant`).
In the latter case, `expectedType` is the type of the property and it
can be a supertype of the actual value (e.g. see `arrayConst` in
compiler/testData/serialization/builtinsSerializer/compileTimeConstants.kt).
But in the former case, we need to check that the value conforms to the
expected type and disregard it if it's not the case, which is possible
if the annotation was recompiled separately.
#KT-28927
Ideally, the type of `IrWhen` should be provided by type inference for
a consistent behavior. `USED_AS_EXPRESSION` from CFG isn't always
consistent with type inference, unfortunately.
The behavior is now aligned with `if`. The type of `when` is kept when
it *can* be an expression, instead of whether it is used or not.
`RuntimeTypeMapper.mapSignature` threw exception because the descriptor
for `clone` was created manually in CloneableClassScope and therefore it
didn't have a JVM signature as in deserialized descriptors, and wasn't
recognized as a Java method either.
#KT-22923 Fixed
Quoted from https://kotlinlang.org/docs/reference/classes.html
"On the JVM, if all of the parameters of the primary constructor have
default values, the compiler will generate an additional parameterless
constructor which will use the default values. This makes it easier to
use Kotlin with libraries such as Jackson or JPA that create class
instances through parameterless constructors."
It's enough to have at least one good constraint.
Note that the whole algorithm can be a bit more general:
we could check also Out<T>, In<T> and verify that T has good only
lower constraint or upper constraint, but there are questions for
types like Inv<Out<T>>, where T should have lower and upper constraints
#KT-31514 Fixed
It uses isStaticMethod to determine whether to set ACC_STATIC, which is
not correct (see PR #2341). This results in using incorrectly typed
opcodes (as all arguments are shifted by 1) when modifying the inlined
lambda's bytecode. For example, in the test added by this commit, these
opcodes are inserted to spill the stack into locals before calling
another inline function.
Because getMethodAsmFlags is used by the non-IR backend (see PR #2341
again for why changing stuff might not be a good idea), the proposed
solution is to ditch it completely and override generateLambdaBody in
IrExpressionLambdaImpl to use FunctionCodegen's IR-based flag
computation logic.
The synthesized arguments caused the size of default value mask off by
one when it is close to the boundary of Int.SIZE, which in turn
resulted in wrong signature at call sites.
in OUTERCLASS field.
The inliner generates two versions of suspend functions/lambdas in
inline functions: with state-machine and without. The former is used
to call the function from Java or via reflection and have ordinary
name, while the latter is used by inliner and have $$forInline suffix.
The inliner throws the state-machine version away, duplicates
$$forInline version and then call state-machine generator.
If these suspend functions/lambdas are not going to be inlined,
$$forInline version is not generated. However, all objects, which are
used in these suspend functions/lambdas, have $$forInline version
written to OUTERCLASS field. This leads to errors by proguard.
Since they are used in both state-machine version and for-inline ones,
we can simply remove $$forInline suffix from OUTERCLASS field and this
fixes the issue.
#KT-31242 Fixed
In 1.3.31 I fixed Java interop for inline function with coroutines
(TL;DR: when we need a state machine, generate two methods: one with
normal name, and the other one with $$forInline suffix, for the inliner
to use, just like inline suspend functions), however, I forgot a case
with inline suspend function with inline suspend function parameter.
In this case, the compiler a generated two functions, as needed, but,
neither of them had a state-machine. This change adds the state-machine
for the method with normal name. Note, that suspend inline functions
with crossinline parameter, which are also supported by the change,
did not cause incorrect behaviour, since until now they were generated
as synthetic.
#KT-31354 Fixed
This change is to fill the gap between Kotlin Collection
classes(immutable) and Java Collection classes(mutable), to avoid
calling an unsupported operation like remove() on an immutable class in
jvm.
Alexander Udalov