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
Instead of requiring to pass it in SerializerExtensionBase's
constructor, pass it always in serializePackage. This is more
straightforward and helps in a situation where one SerializerExtension
instance is used for the whole module, not one per-package
Since now `suspend (Int) -> String` will be serialized as `(Int, Continuation<String>) -> Any?` + suspend flag.
Before this change such type serialized like this: Function2<Int, String> + suspend flag. And yes, type `Function2<Int, String>` isn't correct, because Function2 expect 3 type arguments.
We have special logic for this case and we deserialize such error-written types correctly.
(cherry picked from commit 3518cbe)
Note that now DeserializedClassDescriptor.getSealedSubclasses works a lot
faster than before, for all newly compiled sealed classes except empty ones. It
may be optimized further if we look at the metadata version of the file the
class was loaded from, however it's not easy currently because
DeserializedClassDescriptor is declared in common (non-JVM) code and has no
direct access to the binary version information.
This will also allow to add a reflection API to get subclasses of a sealed
class
#KT-12795 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.
Do not serialize everything in the same package to the same file (as is done
for built-ins) because this approach is unfriendly to incremental compilation,
which is going to be supported in the future. Instead, similarly to JVM
serialize each class to its own file, and each source file with top-level
callables/typealiases to its own file.
E.g. if a file named test.kt contains a class Foo and some
functions/properties, the output will contain two files: TestKt.kotlin_metadata
and Foo.kotlin_metadata. Each one of this files contains the serialized
BuiltIns message (see builtins.proto)
Yan Zhulanow