When checking for class val property reassignment diagnostic, property
initializers should be treated as part of the class initialization.
However, property accessors should not. Previously, only the property
itself was checked for both of these situations and resulted in not
reporting diagnostic within property accessors.
#KT-59744 Fixed
In the following scenario, when we search corresponding expect member
for actual `A.B`, we can skip checking compatibility of `B` scope.
```
class A {
class B {
fun foo() {}
}
}
actual typealias AImpl = A
```
This is because:
1. Annotation checker runs no matter if found expect class is compatible
or not.
2. Class always has at most one corresponding `expect` class (unlike for
functions, which may have several overrides), so we are sure that we
found the right member.
^KT-60668
^KT-60936
Will be needed in subsequent commits for the annotation checker.
`findExpectForActual` is not suitable for the checker because
`findExpectForActual` searches expect class with same `ClassId` for
actual class containing current member (see method
`findClassifiersFromModule`), which is:
1. Unnecessary, since we already have expect class in annotation checker
2. Incorrect when class actualized via typealias and `ClassId` is
different.
So, it is needed to extract logic of searching potential expects
for actual member and already known expect class.
^KT-60668
^KT-60936
Currently, there is only attribute `ExpectForActualAttributeKey`
where mapping is stored only for source declarations with `actual`
modifier. But we need mapping of all class members, including classes
which were actualized via `actual typealias` or fake override members.
This data will be needed for the annotation checker in subsequent
commits.
^KT-60668
^KT-60936
Separate callable and class checks to prepare for checking
class scopes. Extract common checks to separate methods.
Also, it is found that in IR checker annotations on type parameters also checked,
because they stored in `matchedExpectToActual`. But it is expected that
only classes and callables are checked. This started to fail because of
added input parameter type checks inside `areAnnotationsCompatible`.
That's why `expectSymbol is IrTypeParameterSymbol` early-return is added.
^KT-60668
^KT-60936
The main function in this test class to compile a bunch of sources is
`module`, which was changed to test different language versions in
4e706ba93e. But this test uses `compileLibrary` directly, so we need to
pass LV manually.
#KT-60797
Removed TODOs after updating to kotlin bootstrap version with konan.data.dir gradle property changes
Fixed warning of incorrect passing -Xkonan-data-dir arg in konanc from KGP and fixed setting konan-data-dir in SetupConfiguration#setupCommonOptionsForCaches
#KT-60660 Fixed
Merge-request: KT-MR-11299
Merged-by: Dmitrii Krasnov <Dmitrii.Krasnov@jetbrains.com>
In some caches, we assume that the resulting value must be not null if
we provide a context, so we can fix the cache inconsistency in this case.
This is error situations that shouldn't happen, but currently we have
problems with script dependencies (KT-61267), so such checks will help
us to distinguish some LL FIR problems from dependency problems.
^KT-61331 Fixed
^KTIJ-26670
- revert some accidental changes in
`findSmallestElementOfTypeContainingSelection` function (see 48433bf9)
- simplify `dropFakeRootPrefixIfPresent` by using `tail`, add a new
test-case to check that it works
- simplify `findClassifierElementsToShorten` by not passing lambdas and
calling a common functions instead
This reverts commit 529a1dd720.
This commit was needed to workaround broken incremental compilation in
JPS in Kotlin plugin. The incremental compilation bug is reported
KT-60759
As promised in 529a1dd720, after a few
days in `master` I revert it
Review: https://jetbrains.team/p/kt/reviews/11724/timeline
Building Kotlin/Native itself involves running cinterop in the Gradle
daemon process to reduce build time.
But this optimization appears to be incorrect when reusing Gradle daemon
for subsequent builds.
This commit disables the optimization by default, keeping enabling it
possible using `kotlin.native.allowRunningCinteropInProcess=true`
project property.
For more details see ^KT-61300
Originally it used list of declarations, which is incorrect, because
some constructors may be contributed by compiler plugin. And those
constructors will be contained only in scope
Brian Norman