Nikolay Lunyak
a9343aeb7d
This inconsistency is present due to not using the `// WITH_STDLIB` in the above tests. When K1 creates the enum, it tries to generate `entries()`, and for that it tries to load `kotlin.enums.EnumEntries`, but this is actually an unresolved reference. K1 silently swallows it, and proceeds. The reason K2 doesn't fail is that in order to generate `entries()` it simply creates the necessary `ConeClassLikeType` with the desired `classId` instead of loading the whole `ClassDescriptor`. The reason we can still observe `$ENTRIES` and `$entries` in K1 is because they are generated during the JVM codegen, and it only checks if the `EnumEntries` language feature is supported. It doesn't check if the `entries` property has really existed in IR (by this time it's expected to have already been lowered to the `get-entries` function - that's why "has ... existed"). The reason why the codegen doesn't fail when working with `kotlin.enums.EnumEntries` is because it creates its own `IrClassSymbol`. ^KT-55840 Fixed Merge-request: KT-MR-8727 Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
54 lines
771 B
Kotlin
Vendored
54 lines
771 B
Kotlin
Vendored
// WITH_STDLIB
|
|
// IGNORE_BACKEND: JS
|
|
// IGNORE_BACKEND: WASM
|
|
|
|
var l = ""
|
|
|
|
enum class Foo {
|
|
FOO,
|
|
BAR;
|
|
init {
|
|
l += "Foo.$name;"
|
|
}
|
|
|
|
companion object {
|
|
init {
|
|
l += "Foo.CO;"
|
|
}
|
|
|
|
val boo = 22
|
|
}
|
|
}
|
|
|
|
enum class Foo2 {
|
|
FOO,
|
|
BAR;
|
|
|
|
init {
|
|
l += "Foo2.$name;"
|
|
}
|
|
|
|
companion object {
|
|
init {
|
|
l += "Foo2.CO;"
|
|
}
|
|
|
|
val boo = 22
|
|
}
|
|
}
|
|
|
|
fun box(): String {
|
|
try {
|
|
enumValueOf<Foo>("NO")
|
|
} catch (e: Throwable) {
|
|
l += "caught;"
|
|
}
|
|
|
|
if (l != "Foo.FOO;Foo.BAR;Foo.CO;caught;") return "Failure 0: l = $l"
|
|
|
|
l = ""
|
|
enumValueOf<Foo2>("BAR")
|
|
if (l != "Foo2.FOO;Foo2.BAR;Foo2.CO;") return "Failure 1: l = $l"
|
|
|
|
return "OK"
|
|
} |