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
Yan Zhulanow