Alexander Udalov
6e410cb182
The reason is that beforedc02b2e3aband8a0dcca957, 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
17 lines
305 B
Kotlin
Vendored
17 lines
305 B
Kotlin
Vendored
// FILE: JavaEnumA.java
|
|
|
|
public enum JavaEnumA {}
|
|
|
|
// FILE: JavaEnumB.java
|
|
|
|
public enum JavaEnumB {}
|
|
|
|
// FILE: test.kt
|
|
|
|
enum class KotlinEnumA
|
|
enum class KotlinEnumB
|
|
|
|
fun jj(a: JavaEnumA, b: JavaEnumB) = a == b
|
|
fun jk(a: JavaEnumA, b: KotlinEnumB) = a == b
|
|
fun kk(a: KotlinEnumA, b: KotlinEnumB) = a == b
|