Move out utilities which are used both in lowerings and codegen to
JvmIrUtils and JvmIrTypeUtils, and introduce new JvmIrCoroutineUtils and
JvmIrInlineUtils (probably can be renamed or moved somewhere more
appropriate in the future).
In reality plugin key was used only in two ways:
- found corresponding generator for member scope of generated class
- pass it to declaration origin so it can be read in backend IR plugin
Because of first usage plugin key was required to be an object, which
reduces functionality of second usage, because there was no way to
pass any additional info via key to IR (in future this usecase will be
covered with IR declaration attributes, but right now we don't have
them)
So now generator which created some class is now saved in its attributes
and plugins can use any keys they want. And since there is no other
usages of `FirExtension.key` it removed from FirExtension API at all
After that commit it's allowed to register any FIR plugin using
existing extension infrastructure (`-Xplugin` CLI argument,
plugin.xml for IDE plugins, etc)
There is one of checks left unimplemented (FirParcelizePropertyChecker.checkParcelableClassProperty)
because it requires huge commonization of detecting which type can be
serialized and which not, which is not prioritized job for now
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Fixes KT-19853.
The CREATOR field is a static field on a Parcelable class which is not
visible from Kotlin since the necessary metadata would have to be in a
Companion object which may not exist.
This commit adds a [parcelableCreator] function to kotlinx.parcelize,
which is optimized to a direct field access whenever possible.
Anonymous objects in the scope of an inline functions are copied to
all call-sites. This makes them part of the public ABI of a Kotlin
library.
We introduce a flag to mark all classes in the scope of an inline
function. When compiling with assertions enabled, we check that
this flag is set whenever we inline an anonymous object from another
module.
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
Vyacheslav Gerasimov