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.
After the previous change, when being applied to a function type
with receiver it's assumed to work just as it's applied to receiver type
Thus, it's necessary to fix relevant IDE features relied on DSL markers
#KT-23255 Fixed
Whenever the key is absent it means that for some reason
contract can't be defined there.
But we still want to check them properly, thus checkContractAndRecordIfPresent
should work even if contract is inapplicable here
(no ContractProviderKey in owner's user data)
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
Recently, the container for "lookups" has changed to THashSet
And it lead to exception:
java.io.InvalidClassException: gnu.trove.THashSet;
local class incompatible: stream classdesc
serialVersionUID = -8659895033752433145,
local class serialVersionUID = -1699000958968314003
The reasons for different versions of THashSet are unknown
(though likely related to a slightly different classpathes),
but the fix is rather straight-forward
#KT-26011 Fixed
Zalim Bashorov