From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
* It enables subtyping relationship for keys and elements, allowing type-safe and concise manipulations on the context when complex hierarchies of elements (e.g. implementors of ContinuationInterceptor) are present
* It unblocks possibility to implement suspendCancellableCoroutine in stdlib
* Implementing proper polymorphic get and minusKey in AbstractCoroutineContextElement is impossible because it will introduce source-incompatible change
* ContinuationInterceptor get and minusKey are adjusted in a completely backwards-compatible way
Added container builders for lists, sets, and maps.
The new experimental type inference only works for the simple builders
with a single generic type. The versions with nullability and the maps
still require explicit specification of the types. Obviously explicit
specification is required for all users who are not using the new
experimental inference. Improving the type inference is something that
should be done separately and many things – including these builders –
will benefit from it, however, this is not a blocker for these builders
in my opinion.
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".
Vyacheslav Gerasimov