These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
The idea is that we do no longer use `sourceMapBaseDirs` parameter
of `compileKotlin2Js` task to remove prefix from source paths,
but instead preserve the full paths relative to the output directory.
This allows us to avoid duplicate file names and to identify
source files more reliably.
Then, after sources have been embedded in the source map, we remove
several relative prefixes from source paths.
Deprecate specialized unsigned iterators for removal.
Fix compiler tests:
- drop unsignedLiteralsOn1_2 because apiVersion 1.2 is no longer supported
- drop experimental unsigned literals diagnostic test
Make :kotlin-stdlib-js:prepareComparableSource, :kotlin-stdlib-js:prepareBuiltinsSources, :kotlin-stdlib-js:compileJs, :kotlin-stdlib-js:compileJs, :prepare:build.version:writeBuildNumber, :kotlin-compiler:distKotlinc compatible with configuration cache
Relates to #KT-44611
:kotlin-test:kotlin-test-js:kotlin-test-js-it will still have old version as integration test run logic cannot be fully refactored to the new version (approximately till 3.1)
Relates to #KT-44611
- Switch to building stdlib with bootstrap compiler since IR is stable
enough
- Build stdlib with coreLibs by default
- Include JS IR stdlib to kotlin distribution
There is one failing test namely `ValByMapExtensionsTest.doTest`, which
is quite questionable because its checks the use of out projection and
Exact annotation (see KT-18789)
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 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
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.
Vyacheslav Gerasimov