Storage operations are synchronized already,
but BuildDataManager.getStorage is not synchronized,
so maybe it is possible to create multiple LookupStorage
instances.
#KT-22535
#KT-22995
Original commit: 8ab9366ae5
A difference is not obvious when two sets are compared:
there might be just one different element, but
sets would be printed in one line in iteration order
(which is non-fixed for hashsets).
Also the properties:
EXPECTED_JS_FILES_IN_OUTPUT_FOR_STDLIB_ONLY,
EXPECTED_JS_FILES_IN_OUTPUT_FOR_MODULE_STDLIB_ONLY,
EXPECTED_JS_FILES_IN_OUTPUT_NO_COPY,
EXPECTED_JS_FILES_IN_OUTPUT_WITH_ADDITIONAL_LIB_AND_DEFAULT_DIR,
EXPECTED_JS_FILES_IN_OUTPUT_WITH_ADDITIONAL_LIB_AND_CUSTOM_DIR
are hard to distinguish in code and are not convenient to edit.
Original commit: 7881a305d9
JS IC compares proto using a source file path as a key,
so moving file causes recompilation of its usages
unlike JVM IC that uses a class file path as a key.
Original commit: ff2e3ecfc4
JPS marks dirty direct usages of removed classes since 172.* before a build.
Generic IC also marks dirty all subclasses and their usages.
That is necessary because a method from a removed class could be used
through a subclass.
JPS and generic IC logs diverged in 172 branch, but non-JPS tests
were not run on CI.
Original commit: 7712044146
This change is required to have possibility to build plugin against
minor IDEs, which don't have Java. So we want to extract idea-jvm
Original commit: 8203d1c3fe
Standard library is no longer automatically added to the classpath when
-Xbuild-file is used. Before 83b32e11a7f, these tests worked because no
matter whether -Xbuild-file was used or not, the automatically computed
classpath (which erroneously was used to populate content roots in the
compiler) contained the standard library (see
K2JVMCompiler.configureContentRoots)
Original commit: 9e82ab38f0
Otherwise, because there's no explicit dependency and the JPS plugin
loads the compiler from dist, the compiler jar is not rebuilt between
changes in compiler code and running jps-tests
Original commit: 46fa5cfae0
It was already working in JPS, because it see our synthetic classes
as subclasses for SAM's, but with non-JPS build we have to manually
tracking places that should be recompiled after SAM members are changed
Original commit: df533053f9
See the previous commit for information on the kotlin-reflect vs
kotlin-reflect-api distinction.
Add kotlin-reflect as an explicit runtime dependency of most of the test
configurations because even though they all depend on tests-common, the
runtime dependency on kotlin-reflect is not exported from tests-common
to other modules because the projectTests dependency is not transitive.
Original commit: aca74cef0e
Alexey Tsvetkov