This avoids having both libraryJarWithoutIr and default jar artifact,
which points to the same path as libraryJarWithIr, in the dependent
projects' classpath.
Use libraryJarWithIr instead.
For local builds where libraryJarWithIr doesn't contain any IR, this
should have the same effect.
jar task is disabled, but its artifact is still used through
the runtime configuration in the other projects.
In fact, dependent projects get both
libs/kotlin-stdlib-js-1.3-SNAPSHOT.jar
lib/dist/kotlin-stdlib-js-1.3-SNAPSHOT.jar
in their classpath.
However the former artifact is built with libraryJarWithIr task after
jar task is skipped. This leads to a situation during the parallel build
that a dependent project tries to read that artifact
when libraryJarWithIr task writes it.
This commit adds a dependency edge between the disabled jar and custom
libraryJarWithIr tasks, so that the artifact is ready by
the moment jar task has finished.
The presence of "Add kotlin-reflect.jar..." action depends on whether the API
that requires full kotlin-reflect is actually resolved. Since builtins now
do not contain the entire JVM reflect API, but rather the common one,
we need a real kotlin-stdlib instead of dummy one to have 'KProperty1.getter'
symbol resolved.
Now availability of the configuration quick fix depends on
whether the unavailable reflect declaration are actually resolved,
and for that we need a dependency on stdlib.
DiagnosticsTestWithStdLib now require stdlib only.
Move test data accordingly.
The only test that required kotlin-reflect is transformed into
codegen box test.
Like other classes declared in the standard library, construct a mock of
it in JvmSymbols. This is needed to move classes in kotlin.reflect out
from builtins and to the JVM part of the standard library.
This option has no effect on the production code. But in a custom
scenario of a local bootstrap, where the compiler is replaced with the
one where JVM IR backend is enabled by default, this option allows to
switch back to the old backend.
All of these arguments (except the one for compiling experimental
coroutines) are supposed to go away as soon as we fix related problems
in the JVM IR backend.
* In the Kotlin/JVM tasks, move the compiler arguments setup logic to
a separate class, so that it can be reused by the Kapt tasks without
directly referencing the Kotlin/JVM tasks
* In the Kapt tasks, carefully capture the values using the Provider API
so that the task can be serialized for Instant Execution and then
deserialized and executed without relying on the project model
Issue #KT-35181 Fixed
Vyacheslav Gerasimov