[JS IR] Add option for dce mode
[JS IR] Add logging to non useful declarations if appropriate dce mode
[JS IR] Add mode with throwing exception
[JS IR] unreachableDeclaration method is in rootDeclarations
[JS IR] Add js extra help arg with dce mode and include debug.kt to compile unreachableMethod
[JS IR] unreachableDeclaration as internal to not reproduce stdlib api
[JS IR] Fix description of dce mode argument
- Use console.error instead of console.log
- Use JsError instead Kotlin exception for lightweight
[JS IR] Remove body for throwing exception
[JS IR] Remove default parameter in unreachableDeclaration
[JS IR] Process without removing fields and declaration containers
[JS IR] Rename dce mode on dce runtime diagnostic
[JS IR] Use console.trace instead of console.error
[JS IR] Extract JsError
- Fix naming in prependFunctionCall
- Fix description on runtime diagnostic argument
- Using message collector instead of throwing exception
[JS IR] Distinguish unreachableMethods for log and exception
[JS IR] Extract checking of Kotlin packages of IrField
^KT-45059 fixed
Add -X flag to report extra compiler diagnostics which migth break compatibility.
Use the flag to unconditionally check constructors without fear of
prematurely evaluating lazy supertypes.
KT-19234
KT-42404
KT-44583
To be used in the project after bootstrap to get rid of warnings like
"Language version 1.3 is deprecated, ..." which prevent us from enabling
`-Werror` in `:compiler:cli` and other modules.
As soon as JVM IR is enabled by default (in language version 1.5), use
the CLI argument `-Xuse-old-backend` or Gradle option `useOldBackend` to
switch to the old JVM backend.
This flag was added a long time ago, at the time when we weren't sure if
we were going to keep the naming of local and anonymous classes
completely equal to the naming in the old backend. Now that we've
decided that we won't keep it equal and there are a lot of differences
already, it's not useful anymore.
- 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
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
Alexander Likhachev