Reflection expects to see a callable method for a hidden constructor,
thus, it should be a synthetic accessor.
JVM method signature in metadata should point to the synthetic accessor.
Annotations for hidden constructor should be written on the synthetic
accessor.
In MemberDeserializer.loadProperty, we incorrectly passed 0 to
getAnnotations when loading annotations on property accessors in case
the protobuf field getter_flags/setter_flags was not present. The
correct behavior, as described in metadata.proto, was to pass a special
"default accessor flags" value, constructed from the main property
flags. Otherwise in case there were annotations both on the property and
on the accessor (as in PropertyAndAccessor.kt) and the accessor was
otherwise default, we would assume that it had no annotations and would
not load them in compiler and reflection
#KT-25499 In Progress
Note that this change brings an incompatibility: `Array<Foo>::class`
will be seen as `Foo::class` by the old deserializer. We consider this
OK because the compiler never had any logic that relied on reading class
literal arguments correctly (otherwise it wouldn't have worked because
it could only see `Array<*>::class` before this commit), and the support
of annotations on types in JVM reflection is only available in the
upcoming 1.3 release (KT-16795)
#KT-22069 Fixed
Instead of adding new kind of types, we'll use flag to disambiguate
usual types from unsigned ones, this approach has two advantages:
- less changes in the metadata format
- it allows naturally extend format for unsigned arrays,
which will be supported later
#KT-25310 Fixed
#KT-25273 Fixed
Also, fix the value of "hasAnnotations" flag to reflect if there are any
_non-source_ annotations on a declaration.
Unfortunately, after this change
IncrementalJsCompilerRunnerTestGenerated$PureKotlin.testAnnotations
starts to fail because of the following problem. The problem is that
annotations on property accessors are not serialized yet on JS (see
KT-14529), yet property proto message has setterFlags field which has
the hasAnnotations flag. Upon the full rebuild of the code in that test,
we correctly write hasAnnotations = true, but annotations themselves are
not serialized. After an incremental build, we deserialize property
setter descriptor, observe its Annotations object which happens to be an
instance of NonEmptyDeserializedAnnotationsWithPossibleTargets. Now,
because annotations itself are not serialized, that Annotations object
has no annotations, yet its isEmpty always returns false (see the code).
Everything worked correctly before the change because in
DescriptorSerializer.hasAnnotations, we used Annotations.isEmpty and the
result was the same in the full rebuild and in the incremental scenario.
But now we're actually loading annotations, to determine their
retention, and that's why the setterFlags are becoming different here
and the test fails
#KT-23360 Fixed
- Add ContractDescriptorRenderer
- Add option to dump function contracts in DescriptorRendererOptions
- Add parsing of LANGUAGE_VERSION directive in AbstractLoadJava
- Add tests on serialization-deserializaton identity of contracts
==========
Introduction of EffectSystem: 13/18
As the type is anyway replaced with not-nullable version
explicitly, the only thing that changes is what type is loaded
for String[][].class:
- before it would be Array<Array<String?>?>
- now it's Array<(out) Array<(out) String!>!>
It's both a minor change and new behaviour can be considered
as correct
It's only used for CLI compiler, and it should improve performance
of loading Java descriptors from class-files
For IntelliJ, it leads to 10-15% percent speedup of Kotlin Builder
Before this change, we were using a Java model based on Java PSI that
also read class files, but do it less effectively since it performs
some extra work, that we don't need, e.g. eagerly reading all
the inner classes
- Use FULL_JDK instead of mock JDK in some tests because mock JDK is
created from JDK 6 and full JDK is now JDK 8, so there are differences
in the behavior in the compiler and at runtime
- Remove some '*.runtime.txt' files which were workarounds to JDK 6
reflection issues regarding generic inner classes; code in these tests
is now loaded exactly the same in the compiler and at runtime
- Change supertype in SupertypesAndBounds.kt: the class in the supertype
is not relevant to that test, it checks that annotations can be loaded
on types
Use proper initial/frontend version of suspend descriptor
when writing METHOD_FOR_FUNCTION, because serializer uses this version
Also this commit contains adjustments of neighboring code to the describe
change
#KT-16093 Fixed
'SuspendFunction$n' class descriptors are created on demand by KotlinBuiltIns (and cached).
On serialization, types constructed with 'SuspendFunction$n' are written as 'Function$n' with extra flag (SUSPEND_TYPE).
On deserialization, corresponding 'SuspendFunction$n' classes are used.
There are several reasons for doing this:
- See org.jetbrains.kotlin.serialization.deserialization.descriptors.DeserializedMemberScope.computeDescriptors,
classifiers are being deserialized in the last turn, so it's necessary to preserve consistent order
- Their priority should be close to classes
