Added inspections to check:
- custom serializer on class has as many parameters in primary constructor as the serializable class of type arguments
- all parameters in custom serializer has `KSerializer` type
- property in serializable class not parametrized by type parameter
- custom serializer on property of serializable class have no parameters in primary constructor
This is more consistent with the code of
the common compiler checkers.
It would be nice to refactor the contents
of this object further, but it's out
of scope of the current branch.
^KT-54596
For a more efficient lookup of a companion with the functions of obtaining a serializer, a special annotation is added to the named companions.
Merge-request: KT-MR-11003
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
For interfaces with custom serializer (@Serializer(`SerializerType::class)`) now the `serializer()` function is generated in the companion so that user can get a serializer by type
Merge-request: KT-MR-11040
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Serialization requires an instance of the serializer, which cannot be obtained with the passed interface, abstract or sealed class.
Therefore, the specifying of such classes in `Serializable` annotation must be prohibited.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2173
Relates #KT-58036
Merge-request: KT-MR-10753
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
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
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>
K2 plugin API has a limitation that meta annotations from plugin predicates
can't be used on nested annotations because their resolve process includes supertypes
resolve, that can be affected by the plugin itself. Therefore, @MetaSerializable
can't be applied to nested annotation classes in K2, which is reflected by
this diagnostic.
For old FE, diagnostic is lowered to WARNING with deprecation message.
- 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
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.
(Old is created first because all intrinsics emit bytecode anyway)
Provide intrinsic for serializer<T>() function so it won't
invoke typeOf() construction and KType->KSerializer conversion
making it fast and truly reflectionless
Add support for recalculating stack size in plugin-defined intrinsics
since it is needed for correct work:
Unify method for recalculating stack size with existing typeOf intrinsic
Add testdata for IR for future intrinsic in IR
Sergey.Shanshin