* Add configurationName and provide `toString()` implementation for
better debugging experience;
* Update `dependencyArtifacts` and `moduleArtifacts` API to work in the
same way as original Gradle's counterparts
* Add helper extension functions `allResolvedDependencies`
and `dependencyArtifactsOrNull` for better developer experience
^KT-49933
This commit adds finalizers to the custom allocator. Compared to the
existing solution:
* The finalizer queue is replaced by an AtomicStack<ExtraObjectData>.
* All objects with finalizers get meta objects attached. This was not
previously the case for CleanerImpl, but is now needed to link objects
together in the finalization queue.
* The finalizer queue is built during SweepExtraObjects, instead of
during regular sweeping.
* Cleaners are executed by the finalizer thread, and no longer by a
separate worker thread.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-592
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
Related KotlinCompile to JavaCompile wiring is happening on
KotlinJvmTarget initialization before 'withJava' configuration runs. At
that point linked JavaCompile task is null. Fix delays wiring to
execution phase when such task should be available.
^KT-55119 Fixed
Review: https://jetbrains.team/p/kt/reviews/8360
MetadataComparisonTest was the only one in build-tools module who
depended on util-klib, that's why we can drop build-tools -> util-klib
dependency
MetadataComparisonTest is no longer needed, that's why we can drop it.
The dependency drop is a one step forward in dropping
`kotlin.srcDir("../compiler/util-klib/src")` line in
`buildSrc/build.gradle.kts`. Adding source roots in `buildSrc` is hacky
and can lead to frustrations (e.g. KT-55874). That's why it's desirable
to drop buildSrc -> util-klib hacky dependency.
Unfortunatelly, I couldn't drop buildSrc -> util-klib dependency,
because:
1. buildSrc depends on kotlin-native/shared/src/library/kotlin +
buildSrc depends on kotlin-native/tools/kotlin-native-gradle-plugin +
maybe smth else
2. kotlin-native/shared/src/library/kotlin depends on util-klib +
kotlin-native/tools/kotlin-native-gradle-plugin depends on util-klib +
maybe smth else
A LookupSymbol should only refer to either a class, a class member, or a
package member.
When a LookupSymbol refers to a file facade (e.g.,
LookupSymbol(name="FooKt", scope="com.example")), it is redundant as it
doesn't impact the IC analysis to find files to recompile.
Previously, the new IC (ClasspathChangesComputer) would fail when
detecting that IncrementalJvmCache reported these redundant
LookupSymbols. With this change, the new IC will just ignore them.
Note: A better approach would be to fix IncrementalJvmCache to not
report these LookupSymbols, but it will require some significant
cleanup/refactoring work, so we can consider it later.
Test: New KotlinOnlyClasspathChangesComputerTest.testRenameFileFacade
^KT-55021 Fixed
The method must return an empty set in that case, instead of null
that would mean we can't compute it.
The problem was found when running FirLoadCompiledKotlinGenerated
The main idea is pre-computing the sets of names that might be
met there, that helps to decrease the sizes of the backing maps
(by avoiding irrelevant keys)
Totally, this branch with previous commits speeds up MT Full Kotlin
approximately on 3 seconds (~5%)
Avoid filling caches with keys that are definitely empty
(if it's cheap to compute that), to decrease the size of backing maps.
The strategy is pre-computing the sets of names that might be met.
NB: the size of the sets is way fewer than a size of all queried names.
in startCoroutineUninterceptedOrReturn. Otherwise, the coroutine will
not be interceptable later.
Add a test, which checks, that intercepted continuation is released.
#KT-55869
Anton Lakotka