when compatibility variant enabled. commonMain have to be compiled
at least two times. One time to klib and second time to legacy metadata.
In both cases it should have correct classpath.
^KT-49933
* Write transformedLibraries to a file after Task execution
* Write visible source sets to a file after Task execution
* Rearrange task properties, inputs outputs in the way that task state
is serializable to configuration cache.
* Introduce transformDependenciesMetadata task to be an umbrella for
other transform tasks. This will be convinient for tests and other
development purposes
^KT-49933
Remove `createMetadataDependencyTransformationClasspath` that were using
`ResolvedMetadataFilesProvider` which is no longer used by
GranularMetadataTransformation. The transformed files
can be requested directly from resolution results.
^KT-49933
Introduce GranularMetadataTransformation.Params that can be serialized
to Configuration Cache, and it contains all required data for
Metadata Transformations.
^KT-49933
Since ProjectMppDependency[PMS]Extractor is decoupled
from Project it is possible to create MppDependency[PSM]Extractor just
from `ResolvedArtifactResult` using its ComponentIdentifier and file.
^KT-49933
And related ResolvedMppVariantsProvider.
* Introduce PlatformCompilationData that is Configuration Cache friendly
And contain all needed data to infer visible source sets
* Add factory-methods that can collect PlatformCompilationData from
project that has Multiplatform Extension.
* hostSpecificMetadataConfiguration collection has parity with related
ResolvedMppVariantsProvider.resolveArtifacts() part where attributes
are changed to KOTLIN_METADATA.
ResolvedMppVariantsProvider will be deprecated and removed shortly
^KT-49933
* 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.
Anton Lakotka