We do not need running IMPLICIT_TYPES_BODY_RESOLVE to check candidate applicability.
Additional resolve to IMPLICIT_TYPES_BODY_RESOLVE takes about 5% of completion time
^KTIJ-24640
It was failing before, but it was hidden as the actual test was not run due to the bug in the test pipeline.
In the case of any WrappedException.FromHandler were thrown, no blackbox tests were run.
Tracking issue: ^KT-56861
WasmImport annotated functions:
* Restricted to top-level external functions
* Only supports primitive numbers, booleans and Unit
(as return type only) in its signature
* Can't have default parameter values
* Can't have vararg parameters
@JsExport is only allowed on top-level functions in K/Wasm
Restrictions for nested function are handled by reusing K/JS diagnostics
Restrictions for classes and properties are handled by specifying
annotation target in stdlib
Prohibit:
- external enum class
- external tailrec fun
- external suspend fun
- external lateinit var
Add tests for other external diagnostics inherited from K/JS
Now all tests with `Fir` in name are named accordingly to parser which
is used in them -- `FirPsi` or `FirLightTree`. This is needed to keep
consistency between different types of tests, because there is no
single default in parser mode between different scenarios of using FIR
Now this task uses configured freeCompilerArgs both from itself and from
linked KotlinCompile task. When these tasks are configured with the
same value this leads to freeCompilerArgs duplication.
Added workaround is to use linked KotlinCompile freeCompilerArgs as
convention value for KaptGenerateStubsTask. Proper fix will be done via
KT-54468.
^KT-55452 Fixed
^KT-55565 Fixed
Add `getResolvedArtifactsCompat` for compatibility with gradle <7.4
However configurations are still resolved in these gradle versions
^KT-51940 Verification Pending
during tail-call optimization.
There can be code, where all next instructions are non-meaningful and
there is a back-edge, for example, while(true){}. Previously, analyzer
incorrectly assumed, that this cannot happen. Now, it keeps track of
visited instructions and says, that there is no meaningful instruction
in such case.
#KT-56815 Fixed
CoreJrtFileSystem uses JrtFileSystemProvider provider to read contents
of jrt-fs from JDK
Implementation of FileSystems.newFileSystem causes metaspace memory leak
that wasn't fixed until JDK 17, see
https://bugs.openjdk.java.net/browse/JDK-8260621
When FileSystems.newFileSystem used to create jrt-fs on JDK9 with
provided java.home value it creates new ClassLoader under-the-hood,
which subsequently leaks due to aforementioned bug
Remove conditional usage of `java.home` + FileSystems.newFileSystem and
switch to use jrt-fs classloader cache regardless of
compiler runtime JDK to reduce classloader leaks
^KT-56789
Trick codegen into generating getfield from the anonymous class instead
of its supertype (e.g. kotlin.jvm.internal.FunctionReference,
PropertyReference or AdaptedFunctionReference). This gets rid of
unnecessary accessors in some cases, and will help in the subsequent
commit that changes logic around access to fields from Java
superclasses.
Kotlin/Native compiler can compile source files directly to a native
binary (e.g. an executable or a framework). This is the so-called
"single-stage" compilation mode. It is used only in the command-line
compiler, while Kotlin Gradle plugin always produces an intermediate
klib first, and then compiles it to a native binary ("two-stage"
compilation mode).
When running Kotlin/Native compiler with '-language-version 2.0' in the
single-stage compilation mode, it in fact doesn't use the new K2
frontend. This is misleading and error-prone.
To address this problem, the commit prohibits the single-stage
compilation with '-language-version 2.0'. This affects only the
command-line compiler, and shouldn't affect compilation with Gradle.
^KT-56855
Pavel Punegov