Currently, FirLegacyRawContractDescription is a valid class for
resolved contract in case of error description.
This condition should be dropped after KT-60310
^KT-60310
LLFirTypeTargetResolver in general is responsible for annotation
type resolution, so such checks should be done on its phase.
Also, there is no sense to trying to check a type of annotation mapping
values because they will be initialized only during
LLFirAnnotationArgumentsMappingTargetResolver so, in most cases,
current check during LLFirAnnotationArgumentsLazyResolver is useless
^KT-60295 Fixed
The fresh version of intellij has all record-related declarations,
so an additional fake constructor leads to errors like
KTIJ-25364 (OVERLOAD_RESOLUTION_AMBIGUITY)
^KTIJ-25366 Fixed
^KTIJ-25364 Fixed
^KTIJ-25368 Fixed
^KTIJ-25370 Fixed
Problem: fakeOverrideSubstitution was set to null before the return
type was published, so another thread can see a state where
fakeOverrideSubstitution is null and a return type is implicit
simultaneously
^KT-60385
^KT-59758 Fixed
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.
WithExpectedType mode was only needed to replace return type for the
getter, so I made it explicit there
After that, `resolutionMode` in `transformFunctionWithGivenSignature`
became effectively constant
originalDeclaration is set for non-local declarations only,
thus requesting symbols for local declarations still goes
with non-physical elements
This lead to ModuleKind.BINARY_MODULE
for `NotUnderContentRootModule`s, because the declaring file is different
KT-60377
Supported atomic update of elements for IntArray, LongArray and Array<T>
See KT-58360
Merge-request: KT-MR-11020
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
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
Stanislav Ruban