They are a kind of a hack applied in light-classes and it'd be nice
to prevent them being used in irrelevant contexts
kotlin-serialization-compiler module should not depend on idea,
thus we can't use annotations directly there.
So, we copy-paste them and add a test on names consistency
Otherwise, whether LazyLightClassMemberMatchingError happens
or other type of errors because serialization plugin expects
full resolution in the correct module
Currently, only @Serializable annotation leads to exceptions,
but just in case we consider both of them as potentially problematic
#KT-26895 Fixed
Split import handlers into multiple files
Add empty Maven handler for Android Studio
Add testRuntime dependency on kx-serialization-plugin for all modules which require compiler
plugins in test classpath
[IR-plugin] Synthetic property declaration in $serializer
[IR-plugin] Saving most of simple cases
[IP-plugin] Some refactoring and start of work on load func
[IP-plugin] Loading simple case without validation
[IP-plugin] Rebase to IR types and Native-enabled
[IP-plugin] Generating .serializer() accessor in companion
[IP-plugin] Basic synthetic deserializing constructor, fixed some todos
[IR-plugin] Remove reference to SerialDescriptor.init() since K/N now has freeze-aware lazy
Updated version to 0.5.1
Fix resolving serializers for classes from other modules
(Kotlin/kotlinx.serialization/153)
Respect @SerialName on classes
Add support for @SerialInfo on class-level
but from actual KSerializer implementation.
This provides better support for user-defined or external generic serializers
Fix order of resolving serializers: user-overriden should go before polymorphic and default
Don't generate additional constructor if @SerialInfo has no properties
Workaround for recursive resolve
on @Serializable(with) and @Serializer(for) pair annotations
Don't trigger the whole resolve if we need just to check that there is
an argument on the annotation; check PSI instead.
Also, return back check on serializable annotation constructor arguments
Create a version that actually passes a type parameter in write$Self.
This version should take the correct type parameters from the class
rather than adding a function type parameter shared with all
serializers.
Fix for Kotlin/kotlinx.serialization/123: resolve annotation parameters in-place
Fix for Kotlin/kotlinx.serialization/125
Now polymorphic serializer required by all modalities expect final
Breaking changes in compiler plugin:
* Remove java.Serializable supertype
* Move serializer impl from companion to special inner class
* Add generic serializer fields in $serializer and serializer getter
in companion
kotlin.Pair serializer
Generating getter also for non-generic serializers
Generic serializers in JS
Fixed issue when serialDesc property getter was generated, but backing field not.
Respect @Serializable(with=...) on property
Calling 3-arg readElementValue for support of custom contexts
Ability to nest context-based serializer
Migration to 1.2-Beta2
Use polymorphicSerializer prior to default
Don't use polymorphic serializers for all java classes
Docs and maven project update
Remove plugin runtime dependency on stdlib
Fix for JS frontend resolving
Generating serialClassDesc property and save method (w/o virtual calls).
JS Serialization: Load function and synthetic constructor
User-defined serial annotations support
Reference array serialization in JS
Reference array serializer now requires KClass instance as first constructor argument
Finding enum serializer in common module for support in JS
Leonid Startsev