Apparently, using such an approach is a popular case especially for
configuring 'dependsOn' parameter. And we should simplify user migration
to more restricted DSL.
^KT-64722 Verification Pending
Invocation of Logger.fatal() may cause severe side effects such as
throwing an exception or even terminating the current JVM process
(check various implementations of this function for details).
The code that uses Logger.fatal() sometimes expects a particular kind
of side effect. This is totally a design flaw. And it's definitely not
a responsibility of Logger to influence the execution flow of
the program.
These methods are only added to provide more user-friendly error
when user tries to configure JVM toolchain in Kotlin target DSL.
^KT-64629 Verification Pending
Couldn't reproduce the issue in tests or with the reproducer. Most likely the problem was on my side.
^KT-63970 Can't Reproduce
Merge-request: KT-MR-13673
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
Makes it easier to introduce a Gradle property for configuring
IncrementalCompilerRunner.
^KT-64513 Fixed
^KT-63837 In Progress
Merge-request: KT-MR-13671
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
^KT-64121 Fixed
Review: https://jetbrains.team/p/kt/reviews/13495/timeline
If we generate these declarations then the compiler sees Any.{toString,
equals, hashCode} non-synthetic declarations of common metadata and
reports false positive ACTUAL_MISSING during intermediate (HMPP)
metadata compilation.
See the review for more details
This should keep compatability with user scripts that for any reason tried to configure 'sourceSets' container inside KotlinTarget, but keep such users warned.
^KT-57292 In Progress
The purpose of this annotation is to distinguish different levels of DSL
in KGP:
- top level extension
- target level DSL
- compilation level DSL
With this marker user should not be able to call implicit methods from
upper levels of DSL, and it should reduce confusion with DSL usage.
^KT-57292 In Progress
This is an internal annotation that eventually should go away, and the
name is clashing with more public annotation is going to be introduced
in the API project.
^KT-57292 In Progress
Previously, we tried to sync existing Java SourceSet resources into
KotlinSourceSet and then replace Java one from Kotlin. For such an
approach, we called 'files' on existing resources, but this does not
carry information about producing task dependency.
This fix goes a little further and just replaces default KotlinSourceSet
'resources' SourceDirectorySet with a similar object from Java
SourceSet, so any change to Java or Kotlin resources is reflected in
both.
^KT-62490 Verification Pending
Yahor Berdnikau