Dex can't merge class files from both android-extensions-runtime and parcelize-runtime, so we have to keep only one copy of each class.
Instead of @Deprecated annotations, there are new diagnostics (without quick-fixes yet).
The goal is to allow simple usages (@Parcelize alone) but forbid kotlinx.android.synthetic.Parceler usage.
Since IDE does not perform any serialization of descriptors, and
metadata written to the 'serializationDescriptorSerializer'
deleted only on call to DescriptorSerializer,
enabling this extension in the IDE effectively causes memory leaks.
#KT-39624 Fixed
Pass SerializationDescriptorSerializerPlugin to other extensions directly
instead of using static val in companion.
instead of statically registering it.
Static registering can cause subtle errors when plugin implementation
(e.g. SerializationDescriptorPluginForKotlinxSerialization) is registered
from multiple classloaders: in multi-module with daemon compilation scenario
#KT-41857 Fixed
Use it to check that only the value parameters that are explicitly
marked assignable are assigned.
Currently, the only parameters marked assignable are those for
default argument stubs.
The actual problem is a lack of plugin activation check in ParcelableUltraLightClassModifierExtension (see how it should be done in ParcelizeUltraLightClassModifierExtension). However, ParcelableUltraLightClassModifierExtension lays inside ADT sources, and it's impossible to make an fast&easy fix from our side. However, we control the compiler plugin on which the IDE support is based, so the check is added there.
There should be no troubles if the application with 'kotlin-android-extensions' includes an Android library with 'kotlin-parcelize' or vise-versa, as runtime libraries of both plugins are attached to the 'implementation' Gradle configuration since AGP 2.5.
For classes with companion objects, Kotlin compiler generates a 'Companion' static accessor field.
Java prioritizes fields over inner types (apparently, Scala does this as well, KT-29864), so the generated initializer doesn't compile.
As a workaround, initializer generatation is disabled for enum fields inside companion objects. Certainly, it's not a proper fix, however it does fix the regression.
The generated bridges now have line numbers as for the JVM
backend. There are some extra (irrelevant) labels in the JVM_IR
bytecode listing compared to JVM so expectations can still not
be shared even though they are closer.
Yan Zhulanow