yarn.lock can be changed during the build. It means that gradle plugin contain new versions of npm dependencies and yarn.lock should be updated to be actual. From the other side, we have bootstrap checks, and before bootstrap update following bootstrap gradle plugin can contain following changes in Gradle plugin, and in bootstrap checks yarn.lock is not actual.
So when we update NPM versions, we get one of following situations: yarn.lock is actual either in ordinary build or in bootstrap one, and never is actual in both situation
* Use ReflectionFactoryImpl as single point of synchronization
* Synchronize all cache-sensitive tests on it in order to be robust in parallel test runners
* Remove redundant cache clear after each test
Merge-request: KT-MR-6842
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
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
Kristoffer Andersen