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.
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
When IC is on and new Kotlin class is referencing
new Java class, new Kotlin file is compiled twice,
because JPS thinks new Kotlin class is affected by
new Java class (see https://youtrack.jetbrains.com/issue/KT-20318).
This does not happen when IC is off, and KotlinBuilder
requests chunk rebuild (see previous commit).
I decided to remove the reference, because the issue
is now known, and the reference is non critical for the test.
Otherwise unexpected compile error might happen,
when there are Groovy files, but they are not dirty,
so Groovy builder does not generate source stubs,
and Kotlin builder is filtering out output directory
from classpath (because it may contain outdated Java classes).
Previously the issue was not detected,
because it was not possible to turn off the IC completely (in JPS),
only switch to the legacy IC.
#KT-20138
Unlike the JVM target platform, the JS back-end does
not track getters' and setters' usages separately,
so when either accessor of some property is changed,
all usages of that property will be rebuilt.
Alexey Tsvetkov