This is not necessary and incorrect as it dependencies should not leak
to IDE import through this way. So reverting it back to original state.
But for KotlinNativeCompileArgumentsTest update context in the same way
as in Kotlin2JsCompileArgumentsTest and KotlinCompileArgumentsTest
just because KotlinNative Compilation classpath contain stdlib.
^KT-61430 Verification Pending
^KT-61559 Verification Pending
... platform dependencies while filter out them from actual compiler
invocation. So kotlin native compiler will provide them implicitly
from kotlin native bundle. Since K/Native compiler is not yet
optimised to consume platform dependencies explicitly and simply slow.
More details in related issue: KT-61559
^KT-61430 Verification Pending
^KT-61559 Verification Pending
The code is extracted from SetupKotlinNativePlatformDependenciesAndStdlib
as the latter is applied only to native compilations and
shared native metadata compilations.
For test shared native source sets, such as `nativeTest
no native metadata compilation is created, but for legacy import
intransitive metadata dependencies should contain native platform
dependencies listed. And
SetupKotlinNativePlatformDependenciesForLegacyImport fixes that.
^KT-61559 Verification Pending
They are now also exposed via KotlinCompilation.compileDependencyFiles
Which is useful for tools like dokka that relies on exhaustive
list of dependencies for given source set/compilation.
^KT-61559 Verification Pending
This MR fixes two independent issues causing build failures when using Kapt in combination with the Kotlin serialization plugin (and, very likely, with other plugins as well):
Kapt applied compiler plugins twice, causing errors similar to the one described in KT-65006
Kapt failed to generate @Metadata annotations for plugin-generated companion objects because the corresponding SLC missed containingFile needed for generation of method and class signatures
Merge-request: KT-MR-13970
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
This provider is a first step of "Kotlin Native Toolchain".
This solves several problems:
1) Resolving K/N bundle during configuration phase ->
now it happens during execution phase
2) Downloading K/N bundle with internal mechanisms ->
now it uses Gradle dependency resolvers and Transform Artifact
^KT-58303
^KT-52567
^KT-49268
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
Artem Kobzar