* kotlin-experimental.js has been already merged into kotlin.js
* change library name to kotlin in kotlin-experimental.meta.js in order to produce correct require calls
* concatenate kotlin-experimental.meta.js with kotlin.meta.js
* suppress multiple module declaration warning for such use case
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Otherwise IC fails when a project declares a class with the same name
as in one of its dependencies.
The issue is relevant only for non-JPS IC (Gradle, Maven, etc.),
but I added the test for JPS too.
#KT-20516 fixed
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)
Anton Bannykh