KotlinPlatform*Plugins are plugins from pre 1.3 MPP and shouldn't
be used. The intention was to apply usual 'kotlin("jvm")' and
'kotlin("android")'-plugins, for which KotlinPluginWrapper and
KotlinAndroidPlugin stand respectively
kotlin-gradle-plugin-integration-tests on runtime uses relocated
compiler jars. A special handling is required to support this.
Looks like 'kotlin-gradle-plugin-test-utils' was meant to help
here somehow, but was accidentally broken at some point. It went
unnoticed because not much classes from transitive dependencies
of 'kotlin-gradle-plugin-test-utils' were used.
The change in this commit still leaves a few questions about this
configuration, but at leats it makes it possible to use compiler
classes (e.g. KotlinTestUtils)
This changes the logic so that Foo<T> is reported no matter if T is
reified or not. Even for Array<reified T> to align K2 with K1 logic.
#KT-55903 Fixed
Otherwise kapt-generated Kotlin sources do not end up in any module,
which causes an error in KT-58301. The error is only happening with K2
because fragments/fragmentRefines arguments are checked more strictly
than commonSources used in K1.
#KT-58301 Fixed
While dependency is added to backend.native, it's than
transitively packed to :kotlin-native:shadowJar. Without it
running gradle with -Pkotlin.native.useEmbeddableCompilerJar=false fails
with
e: java.lang.NoClassDefFoundError: org/codehaus/stax2/typed/TypedXMLStreamException
KTI-1114
K2 IDE support requires that the entire plugin is in a single JAR, so we
need to have the K1, K2, and CLI (CompilerPluginRegistrar) libraries
available on a single for-ide target.
This reverts commit c9badd14a7.
^KT-57795 fixed
The commit leading to the issue described in KT-58319 was:
510eca9da1
[Gradle] Implement source set inspection methods as 'suspend'
In this commit one method called
'getCommonSourceSetsForMetadataCompilation' was implemented
in a suspend style.
This re-implementation however introduced a semantic change to the function:
Previously this method (counterintuitively) returned commonMain
even if the SourceSet only participated in a single platform compilation.
This is because the KotlinMetadataTarget still cas a 'main' compilation
that includes 'commonMain'. The previous implementation did not filter
this compilation therefore found two platform types for the SourceSet,
assuming that it can be compiled to metadata.
This lead to a 'commonMain' compilation created which then gets
correctly disabled by 'isMetadataCompilationSupported'.
After the commit, a single target project did not create a 'commonMain'
compilation anymore. This leads to no metadata being provided
by the metadata provider. This seems OK, but the 'ProjectMetadataProviderImpl'
threw an error in cases the IDE requested this metadata.
^KT-58319 Verification Pending
Current inline classes API is not compatible between different backends.
So implementing common function required for this optimization
was not possible in Native backend.
So, common default arguments lowering was refactored to make bigger
piece of code replaceable in backends.
^KT-57860
Dmitry Savvinov