It was decided to forbid such comparisons,
as we know how `===` works. Also, added some more
test cases, just for comparison.
Reusing the proper `canHaveSubtypes()`
from `TypeUtils` prevents a breaking change
in:
- `comparingTripleWithPair.kt`
- `comparisonOfGenericInterfaceWithGenericClass.kt`
But it does lead to warnings
(instead of errors) in
`incompatibleEnumEntryClasses.kt`, which is an
unrelated mistake that will be fixed in the next
commit.
The refactoring in `canHaveSubtypes()` is purely
cosmetic - otherwise reading these conditions is hard
(and they don't fit my screen vertically).
^KT-62646
^KT-65541
^KT-57779
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
The reason is that before dc02b2e3ab and 8a0dcca957,
TypeConstructor.isFinal for some class descriptors
(DeserializedClassDescriptor, LazyJavaClassDescriptor,
MutableClassDescriptor) were implemented as `isFinalClass` (which is
`modality == FINAL && kind != ENUM_CLASS`), and all others as
`modality == FINAL` or simply true/false. This led to differences in
behavior depending on the exact instance of the class descriptor.
Now that TypeConstructor.isFinal is always `modality == FINAL`, some
tests (PseudoValueTestGenerated) fail because the finality of some type
constructors changed and these tests render final vs non-final type
constructors differently.
In this commit, TypeConstructor.isFinal is now made to behave safer,
i.e. considering enum class type constructor to be non-final (as was the
case earlier for some ClassDescriptor instances). Some diagnostics might
disappear (e.g. FINAL_UPPER_BOUND) but it doesn't look like a big deal
Nikolay Lunyak