Now when MPP library is published it will contain "sourcesElements"
variant for each target and one for common code.
Sources variants are published under gradle attributes that were
borrowed from Java Gradle Plugin for consistency reasons.
This makes it compatible with JVM tooling that rely on these attributes.
^KT-36943 Verification Pending
This mechanism is simply not necessary anymore.
Just using the 'ownModuleName' as the value of 'moduleName' is
sufficient.
^KT-54312 Verification Pending
To prevent confusing shortcuts defined on `KotlinTargetsContainer`
when declaring a KotlinTargetHierarchy:
e.g.
```kotlin
kotlin {
targetHierarchy.default {
common {
ios() // <- [DSL_SCOPE_VIOLATION]
//'fun ios(): Unit' can't be called in this context
// by implicit receiver. Use the explicit one if necessary
}
}
}
```
^KT-53570 Verification Pending
Test data in `box/annotations/typeAnnotations` is changed because nested
classes in type annotations are rendered differently in JDK 19
(`Outer.Nested` instead of `Outer$Nested`).
#KT-54116 Fixed
This will include Internal* and *Experimental annotations for the
Kotlin Gradle Plugin. The separate module is proposed, so that
additional modules can use those annotations without
a dependency to the full kotlin-gradle-plugin-api module
(see -idea modules)
^KT-54029 WIP
Old one is deprecated and delegates to new options. All new options
are marked with task input types, so they could be used as `@Nested`
input.
Generated options are using specific types in generated
compiler options. This should simplify code completion and provide
meaningful hints to user.
At this point repository compilation will fail.
^KT-27301 In Progress
To avoid exposing compiler internal types inside Gradle DSL public api.
ApiVersion and LanguageVersion in terms of compiler api is almost the
same. Actually ApiVersion is generated based on LanguageVersion. To
reduce user confusion what enum to use and what is the difference
- in Gradle DSL they are now exposed as single enum - KotlinVersion.
Mark KotlinVersion with DeprecationLevel.ERROR if related
LanguageVersion is unsupported and with DeprecationLevel.WARNING if
related LanguageVersion is deprecated.
^KT-27301 In Progress
- just legacy - report warning about deprecation
- both - report warning about deprecation of legacy
- no compiler explicitly chosen - error about explicit setting compiler
warn from cli legacy compiler
nowarn flag - kotlin.js.compiler.nowarn
KT-42326
KT-53074
This will finally make calls to KotlinCompilation.defaultSourceSet
or sourceSets.getByName(compilation.defaultSourceSetName) safe.
This will also enable removing the `kotlinSourceSetsIncludingDefault`
pitfall
^KT-52726 Verification Pending
Anton Lakotka