Added checker for FirEqualityOperatorCall. It's surfaced as one of the
following diagnostics depending on the PSI structure and types under
comparison:
* INCOMPATIBLE_TYPES(_WARNING)
* EQUALITY_NOT_APPLICABLE(_WARNING)
* INCOMPATIBLE_ENUM_COMPARISON_ERROR
Comparing with FE1.0, the current implementation is more conservative
and only highlights error if the types are known to follow certain
contracts with `equals` method. Otherwise, the checker reports warnings
instead.
However, the current checker is more strict in the following situations:
1. it now rejects incompatible enum types like `Enum<E1>` and
`Enum<E2>`, which was previously accepted
2. it now rejects incompatible class types like `Class<String>` and
`Class<Int>`, which was previously accepted
3. the check now takes smart cast into consideration, so
`if (x is String) x == 3` is now rejected
Previously unsafe call is reported as part of InapplicableWrongReceiver.
This makes it difficult for the downstream checkers to report different
diagnostics.
This commits checks iterator/hasNext/next functions whether they are
declared as operator or not. Also, it changes logic of hasNext/next
error reporting, now we're able to report errors about both these
functions.
JavaSymbolProvider uses KotlinPsiElementFinderWrapper for finding classes.
CliFinder looks for Java classing assuming that class with ClassId=a/b/C
lives in directory a/b and do not look into real package name of Java class.
This causes that we may find some classes which we should not see from current scope.
Also, the IDE implementation works correctly here (it also checks file package)
which cause different behaviour of FIR IDE and FIR
This change also requires to fix testdata and make Java classes live
in directory consistent with file package
KotlinJvmBinaryClass.AnnotationArrayArgumentVisitor didn't cover the
case when the element type is an Annotation. Therefore, when the
compiler read an array of annotations from JVM binary classes built from
Kotlin sources, it got an empty array regardless of what was written in
the bytecode.
For example, Foo.value below is read as an empty array when SomeClass
resides in another Kotlin module.
@Foo(
value = [Bar(1), Bar(2)]
)
class SomeClass