To avoid the diamond hierarchy and to allow refactoring the IR element
hierarchy from interfaces to classes, improving performance of visitors
and transformers.
This is needed to get rid of the diamond hierarchy:
IrMemberAccessExpression
/ \
/ \
IrFunctionAccessExpression IrCallableReference
\ /
\ /
IrFunctionReference
In the subsequent commit, IrFunctionReference no longer inherits from
IrFunctionAccessExpression; the more precise type of `val symbol:
IrFunctionSymbol` is now carried via the generic type argument.
This will help to refactor IR element hierarchy from interfaces to
classes, improving performance of visitors and transformers.
Work with the corresponding base interfaces instead. This change will
help in moving the IR element hierarchy from interfaces to classes,
should the need arise.
There's a possible change in behavior in
`CallAndReferenceGenerator.applyCallArguments`, which however doesn't
seem to break anything: IrPropertyReferenceImpl can now also be handled
by this method.
This seems to have no effect on performance, however it clearly shows
that this method is a hotspot now with regard to own CPU samples.
Furthermore, it somewhat decreases the bytecode size at call sites and
might actually allow the HotSpot to inline those methods earlier and
hopefully deoptimize less frequently.
Test failure was caused by "replace custom source root types to a special
'unknown' type and back on plugin unload/load (IDEA-235292)" in intellij.
We override `getModuleSourceRootPropertiesSerializers` in `KotlinModelSerializerService`
by inheriting from `KotlinCommonJpsModelSerializerExtension`
Stacktrace:
java.lang.NullPointerException
at java.io.Reader.<init>(Reader.java:78)
at java.io.InputStreamReader.<init>(InputStreamReader.java:113)
at com.intellij.ide.plugins.PluginManagerCore.getBrokenPluginVersions(PluginManagerCore.java:207)
at com.intellij.ide.plugins.PluginManagerCore.createLoadingResult(PluginManagerCore.java:825)
at com.intellij.ide.plugins.DescriptorListLoadingContext.createSingleDescriptorContext(DescriptorListLoadingContext.java:61)
at com.intellij.ide.plugins.PluginManagerCore.registerExtensionPointAndExtensions(PluginManagerCore.java:1397)
at com.intellij.core.CoreApplicationEnvironment.registerExtensionPointAndExtensions(CoreApplicationEnvironment.java:266)
at org.jetbrains.kotlin.cli.jvm.compiler.CoreApplicationEnvironmentCompatKt.registerExtensionPointAndExtensionsEx(coreApplicationEnvironmentCompat.kt:17)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerApplicationExtensionPointsAndExtensionsFrom(KotlinCoreEnvironment.kt:534)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createApplicationEnvironment(KotlinCoreEnvironment.kt:505)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.getOrCreateApplicationEnvironmentForProduction(KotlinCoreEnvironment.kt:465)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:92)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:88)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:76)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:45)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit(CLITool.kt:227)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit$default(CLITool.kt:225)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMain(CLITool.kt:214)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler$Companion.main(K2JVMCompiler.kt:262)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.main(K2JVMCompiler.kt)
Fixes several tests in 202:
* NewMultiplatformProjectImportingTest
* KaptImportingTest
* ...
This failure was caused by b79ca6e3a855b9d74dba129583d7ed25ecd2f552 in intellij
1. Enum entry fields don't have nullability annotations.
2. Enum class special methods (values, valueOf) are not 'final'
(although they probably should be, javac generates corresponding
methods without ACC_FINAL flag).
3. Enum class special methods don't have nullability annotations.
4. Don't generate synthetic accessor for enum entry class constructor.
KT-37019 KT-37020 KT-37021
* If a KotlinGradleSubplugin implements
KotlinCompilerPluginSupportPlugin, don't apply it as a legacy plugin
* Add the legacy KotlinGradleSubplugin implementations back so that
when there's JAR hell with META-INF/services in the old artifacts
pointing to the classes, loading the plugins with ServiceLoader (legacy
implementation) from the new artifacts would not fail.
* There's a corner case for plugins not in kotlin-gradle-plugin
If a newer and older version of such a subplugin is used with an older
version of the Kotlin Gradle plugin, the latter will find the META-INF
entries and will try to load the subplugins from the new version. With
the original fix for KT-39809, this would result in silently ignored
empty stub implementations.
Given that the Kotlin Gradle plugin can now check if a subplugin
supports the new API, it's OK to keep the old entries and make the
stub implementations throw a build error when called, so that improper
plugin versions are not ignored and are clearly reported.
Note that this is only necessary for the subplugins not bundled in the
kotlin-gradle-plugin module, as those will always be in sync with the
Kotlin version.
Issue #KT-39809 Fixed
The friend paths converted to canonical paths didn't match absolute
paths in the compiler code in case of symlinked directories.
This fixes a regression.
Issue #KT-35341 Fixed
Alexander Udalov