Gradle 8.3+ starts triggering JVM eager tasks creating via eagerly
configured attributes that we copy over from the Gradle JVM plugin for
Kotlin compilation. The fix is to migrate to '.attributeProvider()' API
to configure the attribute.
^KT-60664 In Progress
Restore compiler options DSL for all Kotlin targets. 'KotlinTarget'
interface does not provide any common way to configuring options - this
is the responsibility of related plugin extensions.
From the hierarchical standpoint of view target DSL overrides options
configured in the extension.
^KT-57292 In Progress
- Rename/update to differentiate between 'executed' tasks vs tasks
that are not in the task graph
- de-duplicate assertTasksNotExecuted() / assertTasksAreNotInTaskGraph()
they both did the same thing
- re-use code for verifying all tasks have a specific outcome
- add a more helpful failed assertion message if the task isn't found
- rename 'tasks' to 'taskPaths' for clarity
- Rename/update to differentiate between 'executed' tasks vs tasks
that are not in the task graph
- de-duplicate assertTasksNotExecuted() / assertTasksAreNotInTaskGraph()
they both did the same thing
- re-use code for verifying all tasks have a specific outcome
- add a more helpful failed assertion message if the task isn't found
- rename 'tasks' to 'taskPaths' for clarity
- Rename/update to differentiate between 'executed' tasks vs tasks
that are not in the task graph
- de-duplicate assertTasksNotExecuted() / assertTasksAreNotInTaskGraph()
they both did the same thing
- re-use code for verifying all tasks have a specific outcome
- add a more helpful failed assertion message if the task isn't found
- rename 'tasks' to 'taskPaths' for clarity
- Add an `onlyIf {}` check so CheckKotlinGradlePluginConfigurationErrors
won't run unless there are errors,
which helps writing integration tests and preventing IJ warnings.
- remove unnecessary sequence when fetching DiagnosticsForProject
- update test assertions relating to
CheckKotlinGradlePluginConfigurationErrors
^KT-61943 Fixed
Including checks:
* running embedAndSign through a build phase
* running embedAndSign through a scheme pre-action script
* running embedAndSign through a scheme pre-action script and using Kotlin framework in local SPM package
* absense of explicit '-framework' linker flag
^KT-62376
^KT-63819
K2-only issue. In an incremental build, sourceSet boundary isn't
preserved in certain conditions:
SourceSet A depends on SourceSet B
A and B overload a function, for example:
A -> fun foo(p: Parent) // (1)
B -> fun foo(c: Child) // (2)
If some source file in A is calling foo(..), only (1) is supposed to be visible
for that call site.
However, if
a) it is an incremental build,
b) the declaration of (1) is not a part of the compilation set, and
c) call to foo(c: Child) is applicable,
then (2) would be called from the generated code. So, the build result is not
consistent between the full build and an incremental build.
As a workaround, we fallback to a non-incremental build, if any source from A
needs to be compiled.
To enable "risky" incremental builds, use Gradle property
kotlin.internal.incremental.enableUnsafeOptimizationsForMultiplatform=true
^KT-62686
^KT-63837 Fixed
Merge-request: KT-MR-13695
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
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
Andrey Yastrebov