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
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>
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
- 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
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
In a lot of cases, when we want to process the
declaration in scope, it should be resolved to at least TYPES phase.
To avoid doing it manually in all our variety of scopes, we do it when the scope it created.
It was implicitly working manually before as lazy resolve did a lot of extra work
on resolving a declaration it was not supposed to resolve.
Now it's not the case, and we have to explicitly resolve all the declarations we need.
^KT-56543
Co-authored-by: Ilya Kirillov <ilya.kirillov@jetbrains.com>
`resolvedAnnotationsWithClassIds` requires resolve to TYPES phase,
which is unavailable during compiler plugins stages. Trying to resolve
to that phases will cause an infinite recursive resolve loop
Also, call `resolvedAnnotationsWithArguments` only when
`neededArguments` is true
^KTIJ-24893 Fixed
If an annotation doesn't specify an explicit use-site target,
previously it was added to both, the primary constructor value parameter
and the property in the FIR. Then, in FIR2IR, only the "correct" one was
added to the IR. Move up the deduplication logic into the frontend.
^KT-56177 Fixed
Now all tests with `Fir` in name are named accordingly to parser which
is used in them -- `FirPsi` or `FirLightTree`. This is needed to keep
consistency between different types of tests, because there is no
single default in parser mode between different scenarios of using FIR
These declarations should not be visible to users (and therefore are not added to FIR),
but plugin itself can reference them in already compiled serializable classes,
and therefore they should be available in metadata:
- synthetic deserialization constructor
- static write$Self function
See also:
^KT-55885
If enum class from dependencies is used, which was compiled by a new version of the plugin, which uses a factory and does not create a nested `$serializer` class, then an `SERIALIZER_NOT_FOUND` diagnostic error is thrown for such an enumeration.
This happens if the old serialization runtime is used for the current project - in this case, the serializer is taken from the nested class `$serializer`. Since it is missing, the diagnostics does not work correctly.
It is acceptable for enumerations to ignore this error, because we know that enumerations are always serializable.
Merge-request: KT-MR-8818
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
- Add IrPluginContext to JvmBackendContext, so plugin intrinsics can
reference external functions properly.
- Do not use module.findClassAcrossModuleDependencies as Descriptor API does not work for FIR.
- Add asm listing tests in serialization plugin for K2
- Remove Delegated.kt asm listing test as we have similar test in boxIr group.
#KT-56553 Fixed
Because SerializationJvmIrIntrinsicSupport does not instantiate annotations yet,
this info could be lost. As a workaround, it is possible to call Companion.serializer()
functions instead of direct serializer instantiation, as they are plugin-generated
and correctly handle annotations.
Note that for some cases (enums & interfaces) this WA is not enough, so additional work
is needed later.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2179
This change affects nothing, because @Serializable is checked during
COMPILER_REQUIRED_ANNOTATIONS when typealiases
are not yet resolved, but in case we change something
in the Future and want to support it, we'd have one less problem
`FirDeclarationGenerationExtension.generateClassLikeDeclaration` was split
into two functions: one for generating top level classes, and one for
nested classes. Such change reduces verbosity and error-proness of
this extension and also allows to smoothly run plugins on local classes
^KT-55248 Fixed
as it may have no primary constructor (only actual class has it).
Refactor & rename Fir2IrGeneratorUtils.kt as having 'Fir' in stacktrace
when actual K2 compiler is not used is very confusing.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2134
#KT-55683 Fixed
Name check was forgotten during refactoring, so any user function with
matching signature could be overwritten by the plugin, while correct
function would not have body.
#KT-55682 Fixed
AngryGami