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.
Preface: Kotlin 1.3 will be able to read metadata of .class files
produced by Kotlin 1.4 (see KT-25972). Also, to simplify implementation
and to improve diagnostic messages, we're going to advance JVM metadata
version to 1.4.0 in Kotlin 1.4, and would like to keep it in sync with
the compiler version thereafter. This presents a problem: in an unlikely
event that before releasing 1.4, we find out that the metadata-reading
implementation in 1.3 was incorrect, we'd like to be able to fix the bug
in that implementation and _forbid_ 1.3 from reading metadata of 1.4.
But prior to this commit the only way to do this was to advance the
metadata version, in this case to 1.5, and that breaks the
metadata/compiler version equivalence we'd like to keep.
The solution is to add another boolean flag to the class file, called
"strict metadata version semantics", which signifies that if this class
file has metadata version 1.X, then it can only be read by the compilers
of versions 1.X and greater. This flag effectively disables the smooth
migration scenario proposed in KT-25972 (as does increasing metadata
version by 2), and will be used only in hopeless situations as in the
case described above.
Alexander Udalov