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).
Most of those tests are ignored, because IC is not supported properly
for compiler plugins. This commit is needed to prepare infrastructure,
fix current behaviour and collect main problems of IC with plugins
Check fail.txt files in new testdata for explanation of problems
* kotlinx.atomicfu compiler plugin for JS_IR
Support transformations of atomic operations introduced by the kotlinx.atomicfu library for the JS_IR backend. Compiler plugin is applied externally by the kotlinx.atomicfu gradle plugin.
* Apply compiler plugin for JS platform only
* New plugin test structure
* testGroupOutputDirPrefix changed
Interfaces (regular and sealed) are by default polymorphic. To benefit
from sealing (i.e. knowledge of all inheritors in compile-time), @Serializable
annotation may be added on sealed interface, generating the same serializer
that can be used for sealed classes.
Synthetic nested classes are not generated in DEFAULT_IMPLS mode because
it causes problems when adding a synthetic companion to an interface.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/1576
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
Methods `needToGenerateAdditionalMembersInClass` and
`needToGenerateNestedClassifiersInClass` are removed, now compiler
uses `get...Names` and `getTopLevel...` methods to determine which
extension may generate declaration with specific classId/callableId
This is needed to simplify API of FirDeclarationGenerationExtension and
provide guarantee that `generate...` method will be called with
specific classId/callableId only if specific extensions returned name
for this id from `getName...` functions
Ilya Chernikov