Pinning the language version is rarely the right thing to do.
This changes makes it harder to do so by requiring an additional
directive with a name that indicates to developers that they are
likely doing something dangerous.
For Compose libraries, it is important that libraries built with
K2 in version 2.0 can be read and used by a version 1.9 K1
compiler. That is not possible if custom function types are
in the metadata.
^KT-58456 Fixed
With this change it will have consistent naming with other compiler plugins.
'-embeddable' was also renamed.
'dist' should contain two identical jar files:
- 'serialization-compiler-plugin.jar'
- 'kotlinx-serialization-compiler-plugin.jar'
^KT-58530 In Progress
The code in IrTypeMapper was incorrectly translated from
KotlinTypeMapper during the development of JVM IR. The
`classDescriptor.hasBigArity` condition in KotlinTypeMapper was checking
if the class represents a function or a suspend function with big arity,
and the suspend function part was lost during conversion.
This resulted in incorrect generic signature being generated, which led
to malformed type exceptions from reflection, and compilation errors
from kapt stub generation.
Also, change a comment in irCodegenUtils to avoid confusion of numbered
function types (kotlin.jvm.functions.Function1, ...) with the big-arity
type kotlin.jvm.functions.FunctionN.
#KT-58375 Fixed
FixesKotlin/kotlinx.serialization#2294
If the serializable class contains itself as a property, and its serializer is not an object (for example, for a sealed class), in this case there is a race in the initialization of the serializer and child serializers.
To avoid this the serialization class should not cache its own serializer as a child.
Merge-request: KT-MR-10019
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
The problem results in broken import quick fix and import optimizer on
the IDE side [1].
`AssignResolutionAltererExtension` introduced a possibility to override
resolution of assignment statements. The inconsistency though is
that `KtSimpleNameReference.getResolvesByNames` doesn't return a name
for the overridden `=`. Kotlin as a language doesn't support this [2].
This commit eliminates the drawback above:
1. It fixes the name `assign` the `=` can be resolved to [3].
This eliminates the need to search for the name, bypassing the
plugins.
2. `KtSimpleNameReference.getResolvesByNames` returns `assign` among
other names in case it deals with binary `=` and assignment is
resolved.
3. `KtCompilerPluginsProvider` was extended to check plugins' presence.
K1 implementation added.
----------------------------------------------------------------
[1]: https://youtrack.jetbrains.com/issue/KTIJ-24390
[2]: OperatorConventions.getNameForOperationSymbol
https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments
[3]: OperatorConventions#ASSIGN_METHOD + AssignmentPluginNames
Do not include delegated field into generated constructor even though it
might have backing field.
Test that shows issue was added. Properties that are explicitly marked
as delegated are now excluded.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2091
The tests are removed because JvmDefault is going to be deprecated with
error in KT-54746 and removed later in KT-57696.
Many of the removed tests already had existing counterparts with the new
modes `all` and `all-compatibility`. In this change, I've added such
tests where they were missing, and removed tests which were testing
behavior specific to the JvmDefault annotation, such as some
diagnostics.
#KT-54746
Sometimes when running MPP tests we may
observe js-specific modules running with
the jvm-specific fir2ir converter
(probably because the name didn't contain
the JVM affix).
It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
Fixes #KT-57647
For value classes, if you add code to companion anonymous init block in IR, it will be executed in the instance constructor. This causes an error when initializing static fields, because writing to them can only occur from the <clinit> method.
The solution is to transfer the static field initialization code from an anonymous init block to the IR initializer of this field
Merge-request: KT-MR-9633
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Generate a declaration for each delegated member without body. If we
don't generate delegated declarations, subclasses will have incorrect IR
with unbound symbols in fake overrides.
#KT-58027 Fixed
Otherwise, findTypeSerializerOrContextUnchecked works incorrectly when analyzing code
compiled with Kotlin 1.7.20 and serialization 1.4.1.
#KT-57704 Fixed
Return null instead.
Such behaviour is needed to support cachedChildSerializers logic.
Since this field creator doesn't provide genericGetter (because it's
static),
type param serializer can't be retrieved, and the whole contextual
serializer shouldn't be cached.
#KT-58067 Fixed
Creation of this property in the SerializerIrGenerator.<init> can lead to
a 'Serializer not found' internal error when generator is applied to a fully-customized external serializer.
In that case, generator is still created, but none of the generateSave/Load functions are called,
so cacheableChildSerializers(Property) is not necessary.
#KT-57730 Fixed
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2260
- removed 'kotlin-annotation-processing-gradle' publication as it
duplicated 'kotlin-annotation-processing-embeddable'
- removed 'kotlin-annotation-processing-maven' as it is embedded into
'kotlin-maven-plugin'. Instead 'kotlin-maven-plugin' now depends on
'kotlin-annotation-processing' directly.
^KT-52811 In Progress
- Also publish 'kotlinx-serialization-compiler-plugin-embeddable' to be
used with 'kotlin-compiler-embeddable'.
- Now Serialization Maven and Gradle plugins do not embed plugin into
itself, but declare on published one normal dependency.
- 'kotlin-serialization-unshaded' publication is deprecated.
^KT-52811 In Progress
- also publish 'kotlin-sam-with-receiver-compiler-plugin-embeddable' to
be used with 'kotlin-compiler-embeddable'
- 'kotlin-maven-sam-with-receiver' now just adds
'kotlin-sam-with-receiver-compiler-plugin' as normal dependency
instead of embedding it into itself
^KT-52811 In Progress
- also publish 'kotlin-noarg-compiler-plugin-embeddable' to be used with
'kotlin-compiler-embeddable'
- 'kotlin-noarg-maven' plugin now just adds
'kotlin-noarg-compiler-plugin' as normal dependency instead embedding
it into itself
^KT-52811 In Progress
- also add 'kotlin-lombok-compiler-plugin-embeddable' to be used with
'kotlin-compiler-emebeddable'
- 'kotlin-maven-lombok' does not try to embed plugin into itself and
just depends on compiler plugin as normal dependency
^KT-52811 In Progress
- added also 'kotlin-allopen-compiler-plugin-embeddable' to be used with
'kotlin-compiler-embeddable'
- 'kotlin-maven-allopen' now just depends on
'kotlin-allopen-compiler-plugin' instead of "embeding" it into itself
^KT-52811 In Progress
- rename plugin into 'kotlin-atomicfu-compiler-plugin'
- add 'kotlin-atomicfu-compiler-plugin-embeddable' to be used with
'kotlin-comiler-embeddable'
^KT-52811 In Progress
Move metadata extension with property order from kotlinx.serialization to core
After fix of KT-54792 properties will be deserialized in declaration order
if corresponding class was compiled with modern compiler. But this order
is needed for kotlinx.serialization for binaries compiled with any
kotlin compiler >= 1.4. Since we don't plan to add any extension points
into (de)serialization into FIR, we need to take into account existing
metadata extension from kotlinx.serialization in compiler itself
^KT-57769 Fixed
Dmitrii Gridin