When two functions with matching JVM signatures in the same package
were inlined sequentially, inliner could take a wrong method body from
the cache due to MethodId clash. This manifested with inline classes,
but also was possible with some legal Kotlin overloads with matching
erasure.
Use internal name of the corresponding implementation owner class
instead of FQN of the containing declaration. Such MethodIds can't match
accidentally, because corresponding JVM method signatures would clash.
This should have no effect on the correct code currently because all
properties have at least a getter, but may help in debugging problems
with serialized metadata for properties
Metadata for declarations in multi-file classes is always written to the
corresponding parts, but fields for public const vals are generated into
the facade class.
Before this change, we ran generateBackingField only to generate the
const val field in the facade (because isBackingFieldOwner is true only
for the facade). Besides generating the actual field,
generateBackingField also stores the mapping to the FIELD_FOR_PROPERTY
slice, which is used later in the serializer to serialize the correct
JVM signature of the field to the metadata. However, the mapping was
stored to the incorrect binding map! Namely, the map from the same
ClassBuilder that is used to generate the class, and that is the facade
class builder. But the metadata needs to be generated to the part class,
not the facade.
Surprisingly, there is a test at
reflection/multifileClasses/javaFieldForVarAndConstVal.kt that checks
that kotlin-reflect is able to load the field signature of a const val
in a multi-file class, which is the main use case of this information,
and it passed before this change. The reason the test passed is that
KPropertyImpl.javaField uses JvmProtoBufUtil.getJvmFieldSignature which
mistakenly treats the absence of the field signature in the proto as the
hint that it may be computed naively (just the property's name + naively
mapped type), whereas in fact the field signature was missing
completely. (The fact that absence of a message may mean two things is
certainly a shortcoming of the metadata format and should be revisited
in the future.) This never led to any problem in the real world because
it's easy to prove that the field signature of a const val can always be
computed naively.
After this change, we now run generateBackingField twice: for the
facade's class builder, and for the part's class builder. The actual
field is only generated in the former case. But the mapping computed in
the latter case is used correctly in JvmSerializerExtension to store the
field signature to metadata. Also refactor
generateSyntheticMethodIfNeeded in the similar way, to reduce the number
of `if`s.
When we have a nullable inline class value with non-null underlying
type, corresponding value in unboxed representation is nullable. E.g.:
inline class Str(val value: String)
fun test(s: Str?) = listOf(s)
Here 'test(s: Str?)' accepts nullable 'java.lang.String' as a parameter.
When boxing/unboxing nullable values of such inline classes, take care
of nulls.
#KT-26052 Fixed Target versions 1.3-M2
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
Replace ones from org.jetbrains.kotlin package with new annotations from kotlin.annotations.jvm.
No need to copy them to compile kotlin-reflect anymore.
Then simplify reflect project more: no sources — no need to pack its direct output.
In case of a bridge for a vararg invoke with big arity, the bridge only
has one parameter (array of parameters), and the delegate method has at
least 23 parameters. This assert was added in 77959247d2 and it didn't
cause any tests in master to fail because tests on functions with big
arity are disabled there
Dmitry Petrov