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>
In tests merged from boxAgainstJava in 29b96aa1, some directories were
named slightly differently compared to box, e.g. "property" vs
"properties", "varargs" vs "vararg". This change renames these, moves
some of the tests to more fitting directories, and also renames
"visibility" to "javaVisibility" because it's about Java visibilities
specifically.
If the primary constructor has a vararg parameter, the corresponding
property has an array type. This commit creates the builtin array
types for such properties if the vararg element type is primitive,
e.g., CharArray instead of Array.
Usually FIR enum entry is initialized by anonymous object,
which is the container for all enum entry' declarations.
However, for simple enum entries there is no need of initializer at all.
Currently FirThisReceiverExpression of instance methods are translated
to references of the class' thisReceiver,
not the method's dispatch receiver,
which causes problems with IrFrameMap::typeOf,
as the class' thisReceiver is not in the typeMap.
This commit translates non-qualified "this" references of
instance methods to references of the methods' dispatch receiver.
Inner class constructors should use the argument instead of reading
outer `this` from a field because if such an access happens before a
delegating constructor call, e.g. when evaluating an argument, a JVM
bytecode validation error will be thrown. (The only operation on `this`
allowed before a delegating constructor call is SETFIELD, and only if
the field in question is declared in the same class.)
Nikolay Lunyak