Include new project as build logic included build. Such change will
allow us to start migration into build convention plugins by splitting
buildSrc logic into subprojects.
Checksum tasks uses the directory output, but the directory is not
empty, compiler.zip is among files in target directory. And this is
probably the reason why gradle now claims zipCompilerChecksum should be
added as direct dependency (see the error message below).
Workaround: generate checksum in separate directory and copy the
resulting file to directory with the compiler.zip. Note that `Copy` task
can't be used because it also declares target directory as an output.
Reproduce:
```
gradle zipCompilerWithSignature -Psigning.gnupg.keyName=???????? -Psigning.gnupg.passphrase=test -PsigningRequired=true -Pteamcity=true
```
Error:
```
org.gradle.internal.execution.WorkValidationException: A problem was found with the configuration of task ':zipCompilerSign' (type 'Sign').
- Gradle detected a problem with the following location: '/mnt/agent/work/***/kotlin_CompilerArtifacts/dist/kotlin-compiler-1.9.20-dev-6119.zip'.
Reason: Task ':zipCompilerSign' uses this output of task ':zipCompilerChecksum' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
Possible solutions:
1. Declare task ':zipCompilerChecksum' as an input of ':zipCompilerSign'.
2. Declare an explicit dependency on ':zipCompilerChecksum' from ':zipCompilerSign' using Task#dependsOn.
3. Declare an explicit dependency on ':zipCompilerChecksum' from ':zipCompilerSign' using Task#mustRunAfter.
Please refer to https://docs.gradle.org/8.1.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
```
KTI-1285
Also, adjust NativeIrLinkerIssuesIT after 5f3dad1. See the explanation
below.
5f3dad1 makes -Xlazy-ir-for-caches disabled by default. So the compiler
now deserializes different subsets of IR and in different orders.
As a result, the error message for a test changes. Both error messages
(before and after this commit) are correct, and the selection depends
on the IR deserialization strategy.
Moreover, this commit changes the expected error message to the initial
version, used before -Xlazy-ir-for-caches was introduced.
Before this change `./gradlew help` (with native enabled)
Created immediately: 1322
Created during configuration: 1541
after this change:
Created immediately: 596
Created during configuration: 1509
To know more about configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
K2 IDE support requires that the entire plugin is in a single JAR, so we
need to have the K1, K2, and CLI (CompilerPluginRegistrar) libraries
available on a single for-ide target.
This reverts commit c9badd14a7.
^KT-57795 fixed
It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
Also, fix KGP IT for linkage error messages:
the message text in the presence of compiler caches was changed because
of ab89203, and this commit effectively reverts expected message changes
made in ebaa09a.
Create new targets for K1 and K2-specific jars for the IDE. (These
contain the diagnostics classes generated by the plugins, used to target
quickfixes.)
The existing `parcelize-compiler-plugin-for-ide` target remains
untouched with a K1 JAR dependency, because IJ currently depends on
this. Once IJ is cleaned up, we can remove the K1 reference from that
target, leaving only code shared between frontends.
^KT-57795
- removed 'kotlin-annotation-processing-gradle' publication as it
duplicated 'kotlin-annotation-processing-embeddable'
- removed 'kotlin-annotation-processing-maven' as it is embedded into
'kotlin-maven-plugin'. Instead 'kotlin-maven-plugin' now depends on
'kotlin-annotation-processing' directly.
^KT-52811 In Progress
- rename plugin into 'kotlin-atomicfu-compiler-plugin'
- add 'kotlin-atomicfu-compiler-plugin-embeddable' to be used with
'kotlin-comiler-embeddable'
^KT-52811 In Progress
Those classes mainly include KotlinCoreEnvironment and its dependencies
This change is needed for two reasons:
1. Splitting of some common configuration of compiler from logic of CLI
makes code structure more clean
2. There is a need to add dependency on `:analysis:analysis-api-standalone`
to `:compiler:cli`, because FIR analogue of AnalysysHandlerExtension uses
services from it. But the problems is that standalone AA itself depends
on classes for compiler configuration, which leads to circular
dependency between those modules. Extracting configuration to
`:compiler:cli-base` solves the problem
Yahor Berdnikau