Use the version requierement table of the outer DescriptorSerializer
instance when serializing metadata for a class. Pass parent serializer
to DescriptorSerializer.create to make sure the correct table is used.
Serialize nested classes before the outer class in JS and common code,
to make sure requirements are not lost. Also, split
VersionRequirementTest to JVM and JS
#KT-25120 In Progress
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
The only client of this data is reflection, and since anonymous objects
do not have constructors in the source code, they shouldn't in
reflection as well
#KT-20442 Fixed
The change in DescriptorSerializer is needed so that serialized protos
of enum entry classes which are resolved in sources
(LazyClassDescriptor) and are deserialized from binaries
(EnumEntrySyntheticClassDescriptor) are the same. There are tests on
incremental compilation in JS that check that the serialized proto is
exactly the same after rebuild and after an incremental build.
#KT-22048 Fixed
(See KT-20996)
Old message:
Cannot get FQ name of local class: class <no name provided>
New message:
Cannot get FQ name of local class: class <no name provided> defined in private fun x(): <no name provided> defined in root package in file 1.kt
StringTable.serializeTo was effectively only used for JvmStringTable,
but was declared in StringTable because of the usage in
DescriptorSerializer.serialize (which, in turn, was only used from JVM
codegen)
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
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
When default argument value was present in the expected declaration, we
did not correctly serialize that fact to the metadata for the actual
declaration (`declaresDefaultValue` was used). Therefore, it was
impossible to use that actual declaration without passing all parameter
values in another module, where it was seen as a deserialized descriptor
#KT-21913
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
- Introduce new definitions in descriptors.proto
- Add new corresponding values in Flags.java
- Introduce ContractSerializer and ContractDeserializer, responsible for
for conversion ContractDescription <-> ProtoBuf.Contract
- Add dependency of 'serialization' module on 'resolution' so that it
could see contracts model.
Note that here we do a lot of seemingly unnecessary hoops, which in fact
necessary to respect existing module system (in particular, to be able
to extract ContractDescription declarations from 'descriptors' module to
make them invisible from reflection)
==========
Effect System introduction: 8/18
Turns out, only the parameter's name is needed at all usages of this
method. Such a map is both easier to use (no need to call
ValueParameterDescriptor.getName) and easier to construct (no need to
resolve annotation class, its constructor, its parameters). In this
commit, only usages have changed but the implementations are still using
the old logic, this is going to be refactored in subsequent commits
Serialize class names as qualified names in the string table, not as
simple strings. Otherwise NameResolverImpl crashes on deserialization
because it expects that all class names are indices into QualifiedName
table
This fixes KT-17001 because now 'header' modifier is loaded correctly
for deserialized members and the standard disambiguation in
OverloadingConflictResolver.compareCallsByUsedArguments takes place,
where header members are discriminated against the corresponding impl
members
#KT-17001 Fixed
Alexander Udalov