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.
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.
The default Jar task is disabled, but its archive file is still
configured as an artifact to be published in the 'archives' configuration.
Thus, neither 'install', nor 'publish' tasks could not find this file
when `libraryJarWithIr` isn't triggered and does not build it.
Removing that artifact from the 'archives' configuration artifacts makes
'install' task publish nothing.
Therefore it's better to revert the change so that 'libraryJarWithIr' task
always runs and produces an artifact with the default name.
This reverts commit a9fec211
'base' plugin is enough in this case, given that a couple of tasks is registered and configured manually.
Fix kotlin-reflect dependency to be a project dependency.
The switch `includeStdlibJsIr` now affects which artifact is published:
the one with IR or the one without. Previously it affected
whether or not IR was bundled into the artifact "with IR".
Previously JS IR versions of stdlib and kotlin-test were build
by default using compiler previously built on a buildserver.
It had some issues:
- This required us to advance bootstrap every time we made any
incompatible IR changes. This happens often since IR ABI is
not quite stable yet.
- We never tested the exact combination of compiler and stdlib we publish
We tested:
- new compiler with new stdlib build by new compiler (in box tests)
- old compiler with new stdlib build by old compiler (in stdlib tests)
We published:
- new compiler with new stdlib build by old compiler
After this change JS IR compiler tests, builds and publishes
single configuration:
new compiler with new stdlib build by new compiler
JS IR stdlib and kotlin-test are now built using JavaExec of CLI instead
of Gradle plugin to avoid troubles of loading a freshly built plugin.
This also allows to have a granular dependencies: we don't rebuild klib
if we changed a lowering in a compiler backend, but we do rebuild it if
we changed IR serialization algorithm.
RequiresOptIn should be used now instead of Experimental, OptIn instead
of UseExperimental. See https://github.com/Kotlin/KEEP/pull/201.
This change adds the new declarations only to the stdlib, and supports
them in the compiler. Because of the way compiler loads annotations, we
need to bootstrap it first before deprecating the old annotations and
updating tests.
#KT-34647 Fixed
It was broken after the commit bbdbc2896b,
which included kotlin-stdlib-js-ir project into coreLibs list,
but that project didn't have 'install' task, on which 'coreLibsInstall' depends
Remove sample reference from indexOf(Char) overload: both overloads are on
the same page, and showing the sample for indexOf(String) under indexOf(Char)
is redundant and misleading.
Ilya Gorbunov