Rename to "expect" and "actual" annotation.
This will be needed in next commit to make it clear that
only expect annotation value needs special handling.
^KTIJ-26700
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
It was a stupid copy-paste typo. Please notice that this bug is only
presented in K2. In K1, INAPPLICABLE_TARGET_ON_PROPERTY_WARNING is a
warning.
But in K2, INAPPLICABLE_TARGET_ON_PROPERTY_WARNING doesn't matter as
much because it's only possible when LV <= 1.9. But K2 frontend doesn't
guarantee support of language flags that are < 2.0, anyway.
There are no tests because the test would be too trivial.
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
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
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
Disabling the language feature is supported,
otherwise there are too many tests that
would need to be updated to account for
K2's inability to do it.
The `ifConstVal.kt` test is deleted,
because now it must also be ignored in K2,
and since it is ignored for both the
frontends, and the ignored backends
include all the target backends, this test
is basically unused.
Note that now both the frontends report
`CONST_VAL_WITH_NON_CONST_INITIALIZER`.
for `condition`.
^KT-55196 Fixed
This prevents `FirConflictsExpressionChecker.kt`
from missing conflicting local functions. It used
to due to inconsistencies in assigning `<local>`,
and this commit makes it a bit more
straightforward.
The change in KtClassTypeQualifierRenderer
prevents `FirOverrideImplementTest.testLocalClass`
from failing in `intellij`. It didn't fail for
callables, because `KtCallableSignatureRenderer`
doesn't try to render packages.
^KT-59186 Fixed
Kirill Rakhman