1. Enum entry fields don't have nullability annotations.
2. Enum class special methods (values, valueOf) are not 'final'
(although they probably should be, javac generates corresponding
methods without ACC_FINAL flag).
3. Enum class special methods don't have nullability annotations.
4. Don't generate synthetic accessor for enum entry class constructor.
KT-37019 KT-37020 KT-37021
* If a KotlinGradleSubplugin implements
KotlinCompilerPluginSupportPlugin, don't apply it as a legacy plugin
* Add the legacy KotlinGradleSubplugin implementations back so that
when there's JAR hell with META-INF/services in the old artifacts
pointing to the classes, loading the plugins with ServiceLoader (legacy
implementation) from the new artifacts would not fail.
* There's a corner case for plugins not in kotlin-gradle-plugin
If a newer and older version of such a subplugin is used with an older
version of the Kotlin Gradle plugin, the latter will find the META-INF
entries and will try to load the subplugins from the new version. With
the original fix for KT-39809, this would result in silently ignored
empty stub implementations.
Given that the Kotlin Gradle plugin can now check if a subplugin
supports the new API, it's OK to keep the old entries and make the
stub implementations throw a build error when called, so that improper
plugin versions are not ignored and are clearly reported.
Note that this is only necessary for the subplugins not bundled in the
kotlin-gradle-plugin module, as those will always be in sync with the
Kotlin version.
Issue #KT-39809 Fixed
The friend paths converted to canonical paths didn't match absolute
paths in the compiler code in case of symlinked directories.
This fixes a regression.
Issue #KT-35341 Fixed
* Drop the deprecated mode in the Kotlin/Native link
tasks using sources rather than the intermediate
compiled klib.
* Remove the `allSources` and `commonSources`
properties from the KotlinNativeCompilation, use the
tasks' properties instead.
In addition, made the stepping information for constructor calls
consistent across JVM_IR and JVM. For JVM_IR that stepping behavior
is consistent for enum constructor calls in <clinit> for JVM it
is not.
Mikhail Bogdanov