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>
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>
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
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
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
of the class used in @UseSerializers: Use methods to receive
full list of supertypes.
K1 supertypes() call returned all supertypes, while
IrClass.supertypes and FirClassSymbol.resolvedSuperTypes return only immediate ones.
This lead to a difference in behavior between K1 and K2, and regression
after plugin backend was rewritten from descriptors to IR.
#KT-55340 Fixed
as ISE is more appropriate exception for validation.
Improve SerializerClassLowering.runPluginSafe so precise IrClass
where plugin have failed can be reported for non-fatal errors.
#KT-55296 Fixed
write$Self in K1 is created only on JVM, so we need this check to avoid
creating IR function without original descriptor — it will lead to various
bugs in JS and Native, such as superclass properties missing from output
when super.writeSelf is not found in descriptor.
Fixes #KT-55180
Do not use plugin origin for user-written classes that have @Serializer annotation for some reason. Plugin origin makes them synthetic which is incorrect because they're available in source code. Example of such class: @Serializer(JsonElement::class) class JsonElementSerializer
Merge-request: KT-MR-7627
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
- IR plugin does not use it anymore,
regular annotation instantiation feature is used
(insertion of IrConstructorCall(annotationCtorSymbol)).
- IR plugin still generates `SerialInfo$Impl` class to be compatible
with previously compiled code & libraries.
- Custom implementation over descriptors in IR plugin is removed;
plugin now delegates to the existing lowering with some tweaks.
- $Impl descriptor is removed from FE 1.0 because it is no longer needed
for IR plugin; it shouldn't be exposed to users so FIR doesn't need it either.
- Since language lowering is now used, it is possible to correctly instantiate
SerialInfo annotations with default values even if they are from other modules
and even if they were not processed by the plugin.
#KT-48733 Fixed
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/1574
#KT-54297 Fixed
Properly substitute surrogate UnitSerializer in the Companion.serializer()
function generated on classes that use polymorphic or sealed serializer
by default. (Fixes https://github.com/Kotlin/kotlinx.serialization/issues/1692)
E.g. when substituting T -> Array<T>, write the bytecode for the
Array<...> part for typeOf.
This fixes various issues where either Array nesting levels, nullability
information (for typeOf), or entire reification markers were missing,
causing incorrect outputs ranging from missing `?`s to missing `[]`s to
just reified types not really being reified.
^KT-53761 Fixed
Disable it if we do not have required `noCompiledSerializer` function in
runtime. Leave it enabled in tests.
Rollback some changes for old backend as it is unsupported now.
instead, plugins should emit the code similar to the TYPE_OF one with
a special call to MagicApiIntrinsics.voidMagicApiCall directly afterwards.
This is required because old compiler need to correctly inline code
rewritten by plugin.
Sergej Jaskiewicz