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.
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
Here we introduce ONLY_IMPLICIT_RECEIVER tower level
to support extension lambda calls on local variables,
and soften extension receiver checks to make such extensions visible & applicable.
Also here we try to map arguments twice for functional types
In case Java enum has an abstract member, it has the ACC_ABSTRACT flag
set in the bytecode. However, we should still load it with final
modality to be consistent with Kotlin enums which are always considered
final
#KT-23426 Fixed
I've put `isIncompatibleEnums` to TypeIntersector because I placed
all of its usages after all of the TypeIntersector::isIntersectionEmpty ones
^KT-28225 Fixed
In 1.3, due to changes in language, testdata for some tests can be
different from 1.2
We want to simlultaneously test both versions, so instead of fixing
language version in such tests, we split them into two: one with fixed
1.2, another with fixed 1.3
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
Do not report an error on enum entry without initializer if all parameters have default values
(error is still reported if there is no such constructor, or if the constructor call is ambiguous).
Record resolved call on KtEnumEntry.
NB is the enum entry has a corresponding subclass, we still have to generate the "default" constructor call,
because FE doesn't know about the platform-specific representation of that class and its constructors.
See also KT-14097, KT-15900
rapturemain