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
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.
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.
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.
Standard library is no longer automatically added to the classpath when
-Xbuild-file is used. Before 2be7116b0b, 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)
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
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
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.
Yan Zhulanow