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
An expect class might lack some details and thus seem incorrect to the
compiler, while the corresponding actual class is totally fine.
Due to the specifics of the compiler, this happens more often then it
should (because the compiler actually always analyzes expects along
with actuals, with most references actualized).
For example, in KT-52882 the compiler analyzes an expect class
(TestImpl), but the class refers to the actual interface Test as its
supertype, meaning that the compiler sees TestImpl as a class inheriting
an Objective-C protocol but not an Objective-C class, which is
prohibited. While the actual class has its super types in order.
So, in reality, from both actualized and non-actualized points of view,
the code is totally correct, and the error was reported only because of
the way the compiler handles multiplatform.
Those compiler checks only matter for the actual class anyway, so
disabling them for expect classes is harmless.
^KT-52882 Fixed
Artem Daugel-Dauge