And read commonized klibs in execution time only.
it is possible only when rootOutputDirectoryProperty is marked as
OutputDirectory.
```kotlin
class Producer {
@get:OutputDirectory
val foo: RegularFileProperty
@get:Internal
val bar: RegularFileProperty
}
val foo = producer.flatMap { it.foo.map { it.listFiles() } }
val bar = producer.flatMap { it.bar.map { it.listFiles() } }
```
`foo` file collection will be evaluated at execution time.
Because `Producer.foo` is an OutputDirectory and its content unknown
during configuration time.
But `bar` file collection will be evaluated at configuration time.
Because according to gradle model it is not Output and therefore
its content can be evaluated before task execution.
^KT-61359 Verification Pending
It should be possible to commonize native distribution from clean state
and compile shared native code in the same gradle build with enabled
configuration cache.
^KT-61359 In Progress
Gradle doesn't track removed files in OutputDirectory after task
execution. So if task removed some files and if these files
are added back the task would be still UP-TO-DATE. Which is incorrect.
Executing clean task on empty directory is the same as check that
directory is empty. Therefore, this up-to-date check can be removed.
^KT-62611 Verification Pending
This change is intended to improve the intuition of developers.
After adding the two functions, many times developers (me) have
tried to use the 'wrong' (which is now the new name) function name.
KT-61634
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
Dmitriy Novozhilov