to properly serialize class hierarchies with/or private fields.
JVM only for now, because Native/JS do not have private fields.
Update tests and test data and rebase fix.
Unify formEncodeDecodePropertyCall functions.
Fix incorrect reference to object in writeSelf,
so properties dependent on other properties would be correctly compared
with defaults.
type of the property.
Check for serializer type mismatch only when custom serializer is present
Otherwise, there are too many false positives on e.g. PolymorphicSerializer
#KT-36329 Fixed
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/830
when users write @Transient, they get @kotlin.jvm.Transient, because it's always in auto-import.
This annotation does not work with @Serializable classes; @kotlinx.serialization.Transient should be used instead.
Add quickfix for 'incorrect transient' diagnostic:
'Import kotlinx.serialization.Transient'
A mechanism that allows kotlinx.serialization plugin to preserve the
correct (program) order of properties after serializing/deserializing
descriptors to kotlin metadata, which is needed for correct and stable
json serialization of class hierarchies in incremental/multi-module scenario.
It uses protobuf extensions.
Originally reportFromPlugin method was introduced to address the problem
with loading of DefaultErrorMessages.Extension vis ServiceLoader.
For some cases this extension was not loaded by ServiceLoader because
classes was loaded via different class loader, common scenario here is
compiler plugins. Ideally we should load such extension point via
getService approach, but unfortunately to do that we need project and
DefaultErrorMessages.render is static method for now.
Also with reportFromPlugin approach is a problem -- all diagnostics
reported via this method has the same id: PLUGIN_[WARNING|ERROR|INFO]
and it isn't possible to suppress only one particular diagnostic.
To bypass this problem the new method
initializeFactoryNamesAndDefaultErrorMessages was introduced.
It basically store DiagnosticRenderer inside DiagnosticFactory.
It is not ideal, because one DiagnosticFactory could have different
renderers for different scenarios -- for compiler and for IDE, but
I think that it is better than reportByPlugin approach.
LazyIR was emitted because plugin was not able to declare symbols, only to reference them.
Moreover, declarations added by frontend plugin were also unbound symbols produced by psi2ir,
and declaration stub generator was stubbing them with LazyIR – therefore access to global symbol table is not enough for plugins. IrProvider won't help here, because some functions produced by plugin have circular dependencies.
By moving compiler plugins step between psi2ir and declaration stub generator, both problems are resolved
– unbound symbols produced by psi2ir and compiler plugins are declared where they would be declared if this was a user code,
and only unbound symbols left are external dependencies, which is a correct input for lazy ir.
It is required when enum members contain some special annotations which should be recorded in descriptor.
Due to some recursive/lazy resolve problems, compiler plugin frontend can't infer @Serializable on enum automatically, therefore, we ask a user to explicitly provide it.
Also fix ir tests
- Insert patchDeclarationParents after whole processing
- Copy IR nodes to avoid duplications
- Insert correct type for getter during serialization of properties from parent class
- Do not use irThrowIse because it is broken somewhere in Native backend
- Do not insert typeParameters into IrConstructor;
- Set correct property symbol to IrField;
- Use upper bound as a class descriptor for type parameters.
This will allow to get upper bound's KClass in polymorphic serialization.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/490;
- Lazily add all serializer functions.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/502;
- Don't generate constructor invocation for abstract(sealed) classes deserializer.
Such code is incorrect anyway (you can't create an instance of abstract class) and causes problems in devirtualization when exporting Native libraries.
Steven Schäfer