Developers (me) often forget to remove calls to this debugging
utility. Usually this changes is visible during Code Review but we
shouldn't rely on a sharp eye of a human. It is better to automatically
check it during remote run execution.
It is possible to add source files to task directly. Especially this is
a very popular case for Android integration. Android variants can
contain any number of extra-source files that should be compiled
together with other android-specific sources.
Android specific sources that come from Android source sets already
compiled together as part of "main" fragment (KT-62508).
With this change this logic is extended to any extra sources
that are added directly to the compile task.
^KT-62508 Verification Pending
Java sources can be produced by the task or can be configured with
task dependencies. Previously sources were included into task directly
now they are properly configured with Kotlin Android Source Set.
^KT-63753 Verification Pending
^KT-65426 Verification Pending
Android projects has a number of build type/flavor specific source set.
These source sets are included into compilation of multiple variants.
In Android compilation model they should be compiled together and they
should see each-others declarations. With Kotlin MPP plugin applied
these android source sets gets associated with Kotlin Source Sets
counter parts. However in Kotlin Multiplatform Source sets have
a semantics about "expect/actual" refinement and with K2 it also got
stricter and visibility is checked. This is not compatible with Android
compilation model thus the solution is to merge Android Source Sets
into one K2 Fragment.
^KT-62508 Verification Pending
Setting sources through compile task is not compatible with
Multiplatform K2 because for such sources no K2 Fragment relations
will be set and compilation will fail.
^KT-63753 Verification Pending
Users quite often confuse that compilerOptions in KotlinCompilation is
actually the same object in the Kotlin compilation task. We want to make
our API more straightforward and remove this ambiguity by proposing to
use task compiler options DSL.
^KT-65568 Verification Pending
This commit includes:
1. New subproject :tools:kotlinp-klib that contains the facade for
rendering the metadata in "kotlinp" format given just
KlibModuleMetadata
2. A tool for computing (external) IR signatures that are not directly
available in metadata: KlibKotlinpExternalSignatureComputer
^KT-62340
Change package, artifact group, artifact name, and Gradle module name to
kotlin-metadata and kotlin-metadata-jvm, respectively.
In Kotlin 2.0, kotlin-metadata-jvm library is promoted to stable, and is
a part of Kotlin distribution now.
Note that kotlinx-metadata-klib is left with org.jetbrains.kotlinx group, artifact name and package
because -klib part is considered not stable and for internal use. Since it is still published via Sonatype,
it should have kotlinx group. Therefore, it will have both classes from kotlin.metadata and kotlinx.metadata packages. This is not a problem, because we already had kotlinx.metadata split package between -jvm and -klib before.
#KT-63219 Fixed
In Gradle, there is a bug that leads to race condition,
when we use ivy repo in the settings file.
This bug was solved only in 8.1,
so we supported dependencyManagement in our IT only since 8.1.
For Gradle less 8.1 we just add the same repos to build script.
^KT-65708 Fixed
Change the package name for all *.kt files inside
the :tools:kotlinp-jvm subproject from "org.jetbrains.kotlin.kotlinp"
to "org.jetbrains.kotlin.kotlinp.jvm"
^KT-62340
The "common" subproject keeps only backend-neutral logic and depends
only on :kotlinx-metadata library. It takes the name of the former
project - :tools:kotlinp
The "jvm" subproject depends on the "common" one and also depends
on :kotlinx-metadata-jvm. It gets the new name - :tools:kotlinp-jvm
There is a lot of touched files in this commit. The majority of them
is just moved files (tests, test data, etc).
Only the following files were actually modified:
.space/CODEOWNERS
build.gradle.kts
libraries/tools/abi-comparator/build.gradle.kts
libraries/tools/kotlinp/build.gradle.kts
libraries/tools/kotlinp/jvm/build.gradle.kts
plugins/kapt3/kapt3-compiler/build.gradle.kts
settings.gradle
^KT-62340
This refactoring includes the following:
1. Separate backend-neutral part of the metadata printer `Kotlinp`
from the part that accesses JVM-specifics: `JvmKotlinp`.
2. Introduce `org.jetbrains.kotlin.kotlinp.Printer`: The component
that renders both individual `Km*` nodes and the whole metadata
tree, and does so with the proper indentation.
^KT-62340
Limiting spawned by our Gradle integrations tests Gradle daemons maximum
heap size to 1g helps to reduce memory pressure on the system when
running these tests in parallel. Especially it is actual for our CI
agents.
^KT-65701 Fixed