This commit addresses 1243c641296e74a572a4f274df72a4cda60635c6 in intellij
In intellij they added registration of "com.intellij.psi.classFileDecompiler" in
`JavaCoreApplicationEnvironment`. And because the `KotlinCoreApplicationEnvironment` inherits
`JavaCoreApplicationEnvironment` we don't need to register this EP ourselves.
This commit fixes in 203 tests + 1.4.30 compiler:
```
java.lang.RuntimeException: Duplicate registration for EP 'com.intellij.psi.classFileDecompiler': first in com.intellij.openapi.extensions.DefaultPluginDescriptor@44f464d1, second in PluginDescriptor(name=org.jetbrains.kotlin, id=org.jetbrains.kotlin, path=/home/builduser/.m2/repository/org/jetbrains/kotlin/kotlin-compiler-for-ide/1.4.30-M1-30/kotlin-compiler-for-ide-1.4.30-M1-30.jar, version=1.2)
at com.intellij.openapi.components.ComponentManager.createError(ComponentManager.java:167)
at com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.registerExtensionPoints(ExtensionsAreaImpl.java:262)
at com.intellij.ide.plugins.PluginManagerCore.registerExtensionPointAndExtensions(PluginManagerCore.java:1334)
...
```
- rename fileToPurenessInitializers onto fileToInitializerPureness
- remove redundant check on top-level property
[JS IR] Rename initialis* to initializ* for consistency
[JS IR] Move propertyLazyInitialization property to context from configuration
[JS IR] Add test on lazy initialization properties order
[JS IR] Add multi module for lazy initialization of properties
[JS IR] Move tests onto js.translator
[JS IR] Rename fileToInitializerPureness according to context name
^KT-43222 fixed
This helps to reduce peak memory in lowerings/codegen by a lot.
A more robust approach would be to have a separate BindingContext for
each file, and clear each of them after running psi2ir on it. This would
also lower peak memory usage in psi2ir.
Provide a fallback workaround compiler argument
-Xir-do-not-clear-binding-context just in case BindingContext is in fact
used somewhere and it's not caught by tests.
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
Turns out the issue happens to be that ArrayValue uses a list of values which needs to be translated to an array of the percise type before it is used by callBy
This also addresses handling of arguments after a vararg in an annotation
The CompilerMessageLocation is an implicit part of the binary daemon
protocol so changing it breaks compatibility with older daemons.
This change allows to extend location for non-daemon uses without
breaking the binary protocol.
Nikita Bobko