Java Compilation classpath should have the same user-defined attributes
as Kotlin Compilation.
This also prevents from Gradle variant resolution failures on
Java Configurations in case if user-defined attributes
resolve that ambiguity.
^KT-31468 Verification Pending
Enum-type inherits java.io.Serializable on JVM, so it needs
to be refinement ot avoid TYPE_MISMATCH errors.
Note that for the refinement of Enum-type itself it's necessary
to force refinement of enum-entries, otherwise their supertypes
(and Enum-type specifically) won't be touched
Tests are added on IJ side
^KT-53514
Before this commit, we added Enum.entries only in case when
LanguageFeature.EnumEntries was ON (with an exception in K1/Java case).
In this commit we add Enum.entries unconditionally, and in case
the language feature is OFF we filter them out during tower resolve.
Validate that inline function actually is present in at least on of the
modules, not in all of them. That enables support of MODULE directive
in boxInline tests for FIR.
Also, hide a few minor style fixes in this commit
Ensure that when .entries is accessed from an inline function body
or lambda argument, EntriesMapping are properly generated and used
without excessive mappings and duplicated fields
#KT-53236
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
There is no need to create honest object in case of such simple
calculation. Furthermore, it can be harmful if enum class has
non-constant initializer or property.
#KT-53480 Fixed
When computing impacted symbols of changed symbols, previously we
considered only the supertypes-inheritors type of impact, which is the
most common type. This commit adds the constants-in-companion-objects
type of impact to address KT-53266.
We've also cleaned up impact computation to make it easier to add new
types of impact in the future.
^KT-53266 In progress