- Clean up BuildCacheRelocationIT.testKotlinIncrementalCompilation
- Delete BuildCacheIT.testKotlinCompileIncrementalBuildWithoutRelocation
as it is already covered by the test in BuildCacheRelocationIT
- Add BuildCacheRelocationIT.testKotlinIncrementalCompilation_withClasspathSnapshot
- Updated BuildCacheRelocationIT.testKotlinIncrementalCompilation_withClasspathSnapshot
[JS IR] Fix compilation in tests
[JS IR] Fix test after migrating IC to compiler
[JS IR] Fix memory leak
[JS IR] Move js ic to compiler
Merge-request: KT-MR-5673
Merged-by: Ilya Goncharov <Ilya.Goncharov@jetbrains.com>
When building kotlin.test docs, do not query kotlinlang.org
for stdlib package list, but use the one built locally beside.
This avoids build failures when the site is not available.
These arguments are only used when 'kapt.workers.isolation=process' mode
is used. It allows users to apply workaround for running kapt on newer
JDK version without waiting for a new Kotlin release
^KT-48450 Fixed
to ensure precision (otherwise, rounding errors to milliseconds may
add up and cause unexplainable gaps in the running time).
We can still use milliseconds in the final report after all the precise
sub-build-times have been aggregated.
Don't remove the temporary KONAN_DATA_DIR because it might be still in
use by the Gradle daemon process.
Create a new temporary directory instead.
The tests were introduced in 544447e...fa951f8
Add settings for a more fine-grained control over commonizer features
that will be added in the future
Add setting and KGP flag for optimistic number commonization
KT-51011
Fix the behavior of the common (metadata KLIB) compiler with
hierarchical project structures support as
it analyses usages of annotations from dependencies that are marked
with `@OptionalExpectations`.
The fix on the Kotlin Gradle plugin side is to add the
-Xcommon-sources=... compiler argument to those the invocations of the
compiler, just as it is done with the other compilers.
Issue #KT-49089 Verification Pending
This is done to prevent unintentional side effects from Gradle, which
might act hostile against third-party implementations of Gradle public
API interfaces.
This is to avoid leaking the extension function defined
inside those objects to the global namespaces.
Using these extensions on the receiver outside the
noop object makes no sense.
nataliya.valtman