Despite the FUS services are intended to be scoped to a build, the legacy compatibility service wasn't properly managed and that caused a significant memory leak together with changes in KT-59826.
#KT-62318 In Progress
When friendPaths change, internal symbols from other modules become hidden
or visible. This might change which functions are called, which types
are returned, etc. So we should recompile the affected classes.
Gradle doesn't allow Input policy on FileCollection properties, so we
introduce friendPathsSet. It allows us to keep the ABI of BaseKotlinCompile
unchanged, detect non-incremental configuration changes on Gradle side,
and use normal incremental compilation for everything else.
^KT-61918 Fixed
Merge-request: KT-MR-12372
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
Metadata compilation with name "main" isn't used in Hierarchical
Multiplatform. It used to compile commonMain source set to legacy
metadata artifacts. With Hierarchical MPP common source sets start
to compile to klib metadata.
GranularMetadataTransformation.ProjectData is created for all projects
There was a chance when it is created too early before some projects
evaluation. And if that happened that these projects contained some
subplugins (for example KSP) that add more source sets. Then old
algorithm of collecting sourceSetsMetadataOutputs() would fail with
ConcurrentModificationException. For example in this scenario:
Lets assume we evaluate sourceSetsMetadataOutputs for project with
just one common source set: commonMain.
And therefore one metadata compilation whose default source set name is:
commonMain.
On top of that a subplugin applied to this project. This subplugin
creates additional source set for each metadata compilation.
Then with old algorithm following would happen:
* start iterating over sourceSets
* for `commonMain` source set await its Metadata Compilation
* * When Metadata Compilation gets configured at some point of time
it will reach KotlinCommonSourceSetProcessor.doTargetSpecificProcessing
method. Which will apply subplugins.
* * When subplugin is applied it adds a new Source Set to
the sourceSets collections: CME is occurred!
Adding a source set in subplugins should be regulated
either allow it and fix related side effects OR deprecate it.
The current fix doesn't solve all potential issues with adding new
source sets from subplugins. It primarily focused on CME occurrence
for the case above.
^KT-62299 Verification Pending
as those experimental APIs have shown to negatively affect usages
of stable APIs (because of resolve confusion), whilst also
failing to address popular use cases.
KT-61636
KT-61355
KT-61368
as this will result in losing transitive dependencies from said
project dependency.
KT-59020 is now fixed by detecting this case
before creating the 'IdeaKotlinUnresolvedBinaryDependency'
Caused by: KT-59020
^KT-62029 Verification Pending
Implement an infrastructure for checking IR before JS klib serialization.
Implement the EXPORTING_JS_NAME_CLASH and EXPORTING_JS_NAME_CLASH_ES checks.
^KT-61710 Fixed
To support build cache relocatability, we need to convert absolute paths
into relative paths before storing them in IC caches.
Before this commit, we computed relative paths based on the (root)
project directory and FAIL if some source files are located outside the
project directory.
With this commit, we will NOT FAIL in that case. This means relative
paths may start with "../". It's not "clean", but it can work.
Test: New test in BuildCacheRelocationIT
^KT-61852 Fixed
Buildscripts that used `ios`-shortcut certainly used
`val iosMain by getting` as well, which will lead to Gradle exception
after migration. Mention in the diagnostic message that one should
replace `by getting` with static accessors
^KT-60734
This commit contains two kind of fixes:
1) K2 does not create entries for empty subpackages anymore,
so for the file with 'package foo.bar.baz' it creates an entry
only for the main package 'foo.bar.baz' and not for 'foo' or 'foo.bar'
2) K2 uses changed format of the classpath for third party common lib,
now it looks like other dependencies 'name-of-lib-<version>-commonMain'
instead of 'name-of-lib-metadata-<version>'
1) Update test data according to K2 compiler output
2) Finally switch logic of choosing compiler runner depends on language version instead of deprecated useK2 flag
#KT-60859 Fixed
Alexander.Likhachev