It causes weird failures in functional tests, see KT-60712.
Instead, enumerate all known KGP properties and report only them. Note
that internal properties, unknown to the current version of KGP, won't
be reported. Such cases can appear because of a typo or after migrating
to version of KGP that dropped support for that property. It's not
considered to be a problem at the moment
- Don't use presets (they are deprecated and provoke ERROR, causing
build to fail)
- Drop two JVM targets (cause issues because ambiguous consumable
configuration will be created; proper setup needs disambiguation
attribute, but that's too much for this test)
- Drop jvmWithJava-target (this test case is used in several places
as "just some MPP project", so specific advanced features like
jvmWithJava shouldn't be covered here)
Refer to KT-60745 for proper jvmWithJava support
Test source sets do not participate in the metadata compilations by
default, so the check misses them. This commit just encodes this
behavior into tests, without actually addressing it
KT-60724
- Exclude kotlin-stdlib and kotlin-test from reporting
- kotlin-stdlib wasn't reported, because it doesn't even have Gradle
modular metadata (so no o.j.k.platform.type attribute, and check doesn't
work). This commit explicitly excludes kotlin-stdlib, so that when it
starts publishing Gradle Modular Metadata, nothing would break
- kotlin-test was reported only when it is declared in commonMain,
because we're checking only metadata compilations, and commonTest
isn't compiled to metadata
- Depending on kotlin-test is an odd configuration, but it arises
sometimes (e.g. when people extract some test utilities in a separate
Gradle project)
^KT-58872
- Assert that all dependencies are resolved. Gradle won't fail the build
by default, which might lead to test running in a weird misconfigured
state and producing unreliable results (can be green even though there
are bugs)
- Fix several typos and misconfigurations that were revealed after
adding assertion described above
'KotlinSourceSet.LanguageSettings' is now acts as a wrapper for the
related Kotlin compilation task 'compilerOptions' object, similar to how
'kotlinOptions' is working now.
Source sets consistency check now will ignore shared source sets with no
linked compilation to avoid users need to configure them as well.
^KT-57292 In Progress
Atomicfu compiler plugin supported transformations for K/N:
* atomic properties are replaced with volatile properties and all the operations are delegated to native atomic intrinsics
* atomic arrays are replaced with kotlin.concurrent.Atomic*Arrays
* all other features available on JVM are covered as well (custom atomic extensions, delegated properties, debug tracing)
See (KT-58358, https://github.com/Kotlin/kotlinx-atomicfu/issues/261)
Merge-request: KT-MR-11253
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Previous attempt was at 6807ed6642, but it was reverted in 7771e5914d
(see that commit for the explanation). Now it should be fine to remove
these version requirements.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, namely it fixes the ValueClass.kt kotlinp test.
Language feature InlineClasses is enabled since 1.3. The current lowest
supported language version is 1.4, so any compiler that can read
binaries produced by the current compiler also supports inline classes,
which means that the version requirement is not needed anymore.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, because K2 never supported writing this version requirement properly
due to the TODO in `hasInlineClassTypesInSignature`.
KGP supports only Gradle since 6.8.3, and we run tests on
buildserver only since this version, so we shouldn't try to work if
gradle < 6.8.3.
And in general in MPP plugin we shouldn't support version that is not
supported in KGP
#KT-59278
Do not try to find PSI element, but always use the IR element offsets
instead. This greatly simplifies test data because we don't need to have
custom PSI- and LT- based diagnostic ranges in every test, and K1/K2
behavior also is mostly the same.
The exact offset ranges are not as important for backend diagnostics, so
it's better to have K2+PSI and K2+LT behaving the same.
Sebastian Sellmair