Even though SO may not be correct
overrides sometimes, it feels more
natural to treat fake overrides as...
well, "overrides". And without it
we'd need to make the code in
`FirOverrideChecker` less intuitive.
Make parcelize work consistently with
`FirOverrideChecker`.
Actually, there is a philosophical question about
what to do when a plugin generates a class
in a new package, and this class is red code
(for instance, doesn't implement an abstract
member from a supertype). There's no source
to report such an error, but we probably do
want to run checkers to avoid trying to
compile red code to binaries (because it may
crash in backend, or it may silently work).
Phase COMPILER_REQUIRED_ANNOTATIONS causes errors in the kotlinx serialization tests:
org.jetbrains.kotlin.fir.symbols.FirLazyResolveContractViolationException: `lazyResolveToPhase(COMPILER_REQUIRED_ANNOTATIONS)` cannot be called from a transformer with a phase COMPILER_REQUIRED_ANNOTATIONS.
`lazyResolveToPhase` can be called only from a transformer with a phase which is strictly greater than a requested phase;
i.e., `lazyResolveToPhase(A)` may be only called from a lazy transformer with a phase B, where A < B. This is a contract of lazy resolve
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
When a custom serializer is specified on a type and this type is used in a property of another serializable class, then on the JVM this leads to an error accessing the custom serializer class - because it is private and located in another package.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2495
Merge-request: KT-MR-12877
Merged-by: Sergei Shanshin <Sergey.Shanshin@jetbrains.com>
Otherwise, if complex expressions such as when expressions are
used in combination with the intrinsics we get incorrect stepping
behavior.
^KT-64341 Fixed
same as they were in K1 (see KSerializerDescriptorResolver): internal for
final classes and public for non-final.
Unfortunately, there are no Klib API dumps tests in the compiler, so I tested manually.
#KT-64124 Fixed
`IrGeneratedDeclarationsRegistrar` assumes that all generated functions
are correct from a Kotlin point of view. But `writeSelf` method on JVM
is a static method outside any object/companion object
So to properly calculate containing class for this method we should
generate a dispatch receiver parameter, register the method in metadata,
and then remove the parameter (to make function static)
If a serializable class has generic type parameters, its serializer is not an object
and has a specialized constructor. This constructor was public in K1 and should
be public in K2 so it can be called from other serializable classes
(in case class is e.g., part of sealed hierarchy).
#KT-63402 Fixed
This diagnostic used an incorrect type for rendering (outer class type instead of a property type)
and didn't expand type argument of `KSerializer`.
Also add an additional test case for generic parameters.
#KT-63570 Fixed
To be more consistent with K1, certain diagnostics should be reported
not on the whole properties' types, but on type arguments inside them.
Note that there is still a difference with K2 because K2 reports on a type argument
including its annotations, while K1 used KtTypeReference.typeElement.
IMO, K2 conveys the same or better meaning here, so I am willing to leave this
difference instead of providing PositioningStrategy.
#KT-53861 Fixed
Properly set up dom-api-compat dependency for JS IR tests. Since this dependency is added
automatically for every Kotlin/JS library, it should be present during tests just as stdlib.
As a result, tests for serializable enums were changed since 1.6.0 runtime does not require enums to be explicitly serializable.
This prevents `FirConflictsExpressionChecker.kt`
from missing conflicting local functions. It used
to due to inconsistencies in assigning `<local>`,
and this commit makes it a bit more
straightforward.
The change in KtClassTypeQualifierRenderer
prevents `FirOverrideImplementTest.testLocalClass`
from failing in `intellij`. It didn't fail for
callables, because `KtCallableSignatureRenderer`
doesn't try to render packages.
^KT-59186 Fixed
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>
SerializerFactory is an implementation detail for Kotlin/JS and Native:
it should be added as a supertype to a companion object of certain serializable classes
and `serializer(vararg KSerializer<*>)` function from it should be implemented.
Existing implementation added the supertype, but did not add proper override to FirClass
of a companion, which led to various warnings and errors like 'Abstract function 'serializer' is not implemented in non-abstract companion object'.
Also implemented the addition of SerializerFactory supertype to user-defined companions within @Serializable and @MetaSerializable when necessary.
Also set up proper box tests for FIR+Kotlin/JS combination.
#KT-58501 Fixed
#KT-59768 Fixed
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>
Relates #KT-57647
If a serialization descriptor is used in the companion, then when accessing the child elements, an array of cached child serializers may be read.
Since the serialization plugin adds its declarations to the class after the declarations from the source code, the initialization of the array of child serializers occurs after the execution of the user code.
This can lead to N PE errors when trying to access an unfilled cached child serializer.
The solution is to change the order of declarations so that the declaration with the property of cached child serializers comes first.
Merge-request: KT-MR-10545
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Kotlin 1.7.20 added optimizations for delegated properties on the JVM,
which broke serialization for optimized properties. Commit bfeff81
tried to fix that, but broke non-optimized delegated properties. This
commit restores correct serialization for optimized and non-optimized
properties, also ensuring that it only affects the JVM target.
#KT-58954 Fixed
#KT-59113 Fixed
Fixes #KT-58918
If the serializable class contains itself as a generic parameter of the 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.
Merge-request: KT-MR-10363
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
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
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
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
Nikolay Lunyak