single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
In partial module compilation, especially inside the IDE, only a few
files from the project are passed to fir2ir. FIR in these files might
contain references to declarations from other files.
As the FE doesn't usually care about called property initializers,
called properties might be resolved to 'CONTRACTS' or even 'STATUS'.
The backend, however, might need to inline constant expressions from
properties.
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
Dmitriy Novozhilov