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 call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
- support common modules metadata compilation under flag (it is not required since all common source roots are included transitively for now)
- introduce expect actual tracker in jps: move implementation from gradle to build-common
- support js incremental compilation: move implementation from gradle to build-common
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Since d0ca0dca2b
first IC build uses CompilationMode.Rebuild instead of Incremental
to avoid unnecessary work (computing API difference etc.).
However there is a branch that does not transform source files
paths to absolute ones before writing them to module xml file.
In our plugins we have always transformed files to absolute ones before
passing them to IncrementalJvmCompilerRunner, so there is no problem.
But third party build systems could pass relative paths to IncrementalJvmCompilerRunner
(namely Kobalt does so).
It turned out to break builds because KotlinToJVMBytecodeCompiler takes
module xml file's (which is a temporary file itself) parent as a base
for relative source files (see KotlinToJVMBytecodeCompiler.getAbsolutePaths).
This change ensures that makeModuleFile always uses absolute files.
#KT-22542 fixed
Alexander Udalov