The enumEntriesIntrinsicMultipleEnums.kt test was supposed to check that
JVM backend generates 3 `$EntriesIntrinsicMappings` classes: for X, for
Y, and for Z. Mappings classes are generated for enums without
`entries`, i.e. Kotlin enums compiled without `EnumEntries` language
feature, and Java enums. The test incorrectly _enabled_ the language
feature for X though, and `$EntriesIntrinsicMappings` for X was
generated anyway because of KT-61208.
To keep the original intention of the test, I'm disabling the language
feature for X, so that it will be considered as enum without `entries`.
KT-61208 will be fixed in a separate commit (with separate tests).
The boxInline and bytecodeText tests changed their meaning when language
feature EnumEntries started to be enabled by default, so those changes
are a continuation to ebd43fc8c0. The behavior did not change after
enabling the feature, once again because of KT-61208.
Also, remove obsolete error suppressions which are no longer needed
after 64c8ce18a0.
Implementation is very similar to the `enumValues` intrinsic.
Java enums and old (pre-1.9) Kotlin enums will be supported in a
subsequent commit.
#KT-59710
Leveraging the same mechanism with $EntriesMapping as Java enums.
Old (compiled with LV/AV < 1.8) enums are detected by looking for
static special <get-entries> method that cannot be introduced on
Kotlin enums otherwise
#KT-53236
Alexander Udalov