- Use a more generic `-Xallow-unstable-dependencies` instead of
`-Xallow-jvm-ir-dependencies`
- Change `-Xir-binary-with-stable-abi` to `-Xabi-stability=stable`, with
an additional option to specify `unstable` after a subsequent commit
where JVM IR becomes stable by default
#KT-43592
Report a separate error when class files compiled with FIR are in
dependencies, in addition to the one for class files compiled with FE
1.0 + JVM IR.
#KT-43592
Introduce an enum DeserializedContainerAbiStability with two values.
This is needed in order to support another reason for ABI instability in
a subsequent commit, namely "unstable because compiled by FIR".
#KT-43592
All of new classes lays in lays in :compiler:tests-common-new module
which includes classes for FE 1.0 and FIR diagnostics tests and
JVM black boxtests
It's necessary to read preview-features related Java PSI parts
It should be OK to set it unconditionally because we don't compile Java
sources, only obtain declaration structure from them
- Fix line separator issue
- Always quote args with delimiters (=, :)
- fix one of args files by removing obsolete stdlib reference
- Fix kotlinc.bat to ensure lazy evaluation of additional classpath
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
The disposable which decrements ourProjectCount was a non-capturing
lambda, meaning it had a single identity and could only be registered
in the Disposer tree once. Therefore the application environment
would never be disposed if ourProjectCount ever went above 1.
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.
Compute FQ name of the main class right after running the analysis and
before invoking codegen. This is needed because MainFunctionDetector
depends on BindingContext, and JVM IR needs to clear BindingContext as
soon as it's not necessary to reduce peak memory usage, thus breaking
any usages of data from it after the codegen.
Also refactor and use the extracted, but not properly reused previously,
copy of findMainClass in findMainClass.kt.
Note that this replaces NPE in KT-42868 with an UOE.
Denis.Zharkov