Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
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.
This has no effect on the correct code currently, but will help in
debugging when changing the serialized metadata for properties.
For example, if after some change an empty propertySignature extension
is written for Property (it's possible for PropertyDescriptor without
getter or setter and without backing field), we now won't try to read a
missing getter message when loading annotations on property getter. In
protobuf, reading a missing message will result not in an exception, but
in a "default" message being returned, which makes no sense in our case
because it would simply be read as a getter signature with both "name"
and "desc" equal to 0 (i.e. the first entry in the string table)
Decide on completion order by other factors
Previously would prefer callable that return Unit if Unit is the expected type
leading to strange completion order
#KT-25588 Fixed
* Set canBeConsumed = false only on those configurations that have this
flag according to the Gradle Java plugins. This saves us from breaking
existing build scripts but introduces ambiguity between consumable
configurations (e.g. between `apiElements`, `compile`, `runtime`). See
the solution in the next point.
* Don't set the Kotlin platform attribute on configurations that are
not meant for consuming in other projects or resolving directly. This
change hides these configurations from Gradle's variant aware
dependency resolution and therefore prevents ambiguity
(cherry-picked from 81f2c48f)
Moved SubpluginEnviroment to separate file and made public some methods
KotlinNativeCompile task now extends AbstractCompile so it could be passed to SubpluginEnviroment.loadSubplugins
KotlinNativeBasePlugin now declares kotlinCompilerPluginClasspath configuration
Pavel V. Talanov