A mechanism that allows kotlinx.serialization plugin to preserve the
correct (program) order of properties after serializing/deserializing
descriptors to kotlin metadata, which is needed for correct and stable
json serialization of class hierarchies in incremental/multi-module scenario.
It uses protobuf extensions.
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
The old compiler will crash if it tries to inline a function that's
passing a lambda parameter into the new parameter null check method
`Intrinsics.checkNotNullParameter` because that usage is not considered as
inlinable by the old compiler (it only knows about
`Intrinsics.checkParameterIsNotNull`). Therefore we require that these
functions can only be read by compilers of version 1.3.50 or greater.
#KT-22275 Fixed
Local aliases can be copied as-is to a different fragment now. Before this change we would have had to extract the local alias tag (if any) from the source fragment and add to the destination fragment name bindings.
Module references were stored as plain JsName's. When inlining a function
from one fragment to another, those references should be re-interpreted
in terms of the destination fragment. Storing the whole module information
makes that much easier.
Functor is an imperative representation of function's contract (contrary
to ContractDescription, which is a declarative one). ContractDescription
is convenient when we deal with sources of contracts declarations
(binaries, source), while Functors are convenient for analyzing code
with contracts.
It means that we have to convert ContractDescription into Functor when
we start working with contracts. This computation isn't trivial, and
Functor and ContractDescription are in 1-1 correspondence, so we would
like to cache Functor for each ContractDescription somewhere.
We used to do this in binding trace, in slice FUNCTOR.
Now, it turns out that this approach causes "Rewrite at slice"
exception, see KT-28847. We won't go into details of why that happens
here, you can see the issue comments for details (but be prepared for the
very long and nitty-gritty story)
This commit removes the problematic slice and introduces another
approach, where Functor is attached to the ContractDescription, computed
lazily and cached here.
^KT-28847 Fixed
Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
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
After this change, optional expected annotations will be compiled to
physical class files on JVM, and stored to metadata on other platforms,
to allow their usages from dependent platform modules. For example:
@OptionalExpectation
expect annotation class A
When compiling this code on JVM, A.class will be produced as if the
class A did neither have the 'expect' modifier, nor had it been
annotated with OptionalExpectation. Note that if there's no actual
annotation class for A, then usages (which can only be usages as
annotation entries) are simply skipped.
Class A will be public from Kotlin's point of view (since it should
be possible to use it in Kotlin sources), but _package-private_ in Java
to disallow its usages outside of the declaring module.
#KT-18882 Fixed
#KT-24617 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
It's only used for DeserializedPackageMemberScope that's being created
during initialization
At the same time, protobuf objects may be not very light-weight
(see 2e933a165a)
#KT-24513 Fixed
- DeserializedPackageFragmentImpl doesn't actually need member scope to be lazy
in a sense of optimization. It was only necessary for breaking
initialization cycle: DeserializationComponents <-> DeserializedPackageFragment
- For MetadataPackageFragment it might be useful to have
member scope actually lazy since it has O(n) complexity when n is a number
of package parts
This change is helpful for avoidance of storing reference to package-proto
#KT-24513 In Progress
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
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Leonid Startsev