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)
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.
Abduqodiri Qurbonzoda