In order to properly analyze top-level property initialization, a
control-flow graph must be created for FirFiles. This change adds the
foundation for the file CFG and updates body resolve to create the CFG.
Checking the CFG for proper initialization is separated into a following
change to ease code review.
KT-56683
I don't really know which exact commit fixed this test, but there was
a problem with return types of delegated members. Before my changes
delegated `override fun foo(x: Int)` in `actual class E` had error
return type and now it has correct type `Int`
^KT-61039 Fixed
KT-59739 is now open for K1 (but fixed in K2)
Review: https://jetbrains.team/p/kt/reviews/11867/timeline
This partially reverts commit 4f3ecedbca.
Only K1 part is reverted.
Motivation for revert: KT-59739 cannot be properly fixed in K1 because
of the bug it causes - KT-61039
We just accepted that we will have one more "green in K1 -> red in K2"
case
In scope of: KT-22841
Review: https://jetbrains.team/p/kt/reviews/11867/timeline
Reduce complexity by reusing "expect-actual matcher" (namely
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`)
The current solution has worse algorithmic complexity. Previously it was
O(n) in the best case, where `n` is a number of members. Now, it's
O(m^2), where `m` is number of members in one overload group. But we
prefer to have worse complexity but reuse expect-actual matcher, number
of elements in one overload group shall not be big on real world
examples.
The previous logic was non-trivial because it compared types with with
double comparison in `equals`.
Motivation: the discovered false negative in test
changeModalityFromAbstractToOpenInOverride.kt
Unfortunately, it can't be fixed in K1, so we will just live with that.
Luckily, we report ABSTRACT_MEMBER_NOT_IMPLEMENTED additionally.
In K2, MODALITY_CHANGED_IN_NON_FINAL_EXPECT_CLASSIFIER_ACTUALIZATION
will be correctly reported as a compilation error
In scope of: KT-22841
Review: https://jetbrains.team/p/kt/reviews/11867/timeline
Reporting it for `VIRTUAL_MEMBER_HIDDEN`
is ok, because `VIRTUAL_MEMBER_HIDDEN`
has always been an error, so we are
allowed to treat these as overrides
implicitly.
^KT-59408 Fixed
^KT-59419 Fixed
^KT-57076 Fixed
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
It was reported because in composite module analysis we have both expect
and actual annotation descriptors, which may differ.
This may lead to bugs in the checker of ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT
diagnostic.
`fqName` comparison can be safely removed, because we already check
types in `areCompatibleExpectActualTypes`.
Tests:
- typealiasedAnnotation.kt - for annotation use (so it has different
ClassId)
- typealiasedAnnotationAsArgument.kt - when typealiased annotation
used in another annotation as argument
- sourceRetentionAnnotationsWhenTypealias.kt - tests same as
compiler/testData/diagnostics/tests/multiplatform/annotationMatching/sourceRetentionAnnotationsWhenTypealias.kt
No special test added for opt-in, because it's prohibited to have
expect/actual opt-ins by EXPECT_ACTUAL_OPT_IN_ANNOTATION checker.
^KTIJ-26700
This behavior wasn't intended during KT-15470 coding. I only intended to
prohibit `@get:` target on things different from properties. But I
accidentally prohibited `@property` on things different from properties
too
But it's a bug fix anyway, so let's keep it.
I also re-checked the implementation of KT-15470, I don't see any other
unintentional prohibitions
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