They were added in e4702bf438 and a08cf59017 but in fact they are not
needed on JVM until there are JVM-specific extensions in the metadata.
Moreover, there was a typo in JvmValueParameterExtensionVisitor's
superclass (see https://github.com/JetBrains/kotlin/pull/4613).
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
Move it to build-common where it's still used in incremental compilation
caches, and simplify a bit. In the future, it'll make sense to remove it
completely and to avoid writing it to caches. In this commit, I don't do
that to prevent the IC cache version to be updated, causing rebuilds for
all JPS projects.
#KT-41758
The main reason for this change is that the current API for class
version requirements (`KmClass.versionRequirements`) makes it impossible
to support pre-1.4 metadata where this was stored incorrectly for nested
classes: with the "version requirement table" in the outer class, and
indexes into that table in nested classes. See KT-41011.
Other than this aspect, metadata of classes is basically the same in
pre-1.4 and 1.4, which means that if some kotlinx-metadata-jvm users
really need to serialize metadata of an earlier version and they don't
care about the version requirements issue, they can just use these new
bytes but write the earlier version (e.g. 1.1) to the class file.
Everything will work the same, except for the possible version
requirements issue mentioned above.
Note that metadata version 1.4 is still supported for
`KotlinModuleMetadata.Writer` though.
#KT-41011 Fixed
kotlinx-metadata-klib can't have jvmTarget 1.6 because it embeds module
:compiler:serialization which is compiled with jvmTarget 1.8. It is
enforced by configuration error in Gradle 6.5
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
It turns out that `jvmTarget` and `javaHome` settings in
build.gradle.kts were changing the module settings and affected the
compilation of kotlinx-metadata-jvm sources. The correct way to use JDK
8 in tests would be to change JVM target / JDK home of the specific
KotlinCompile task via its `kotlinOptions`, but JarContentTest doesn't
need JDK 8 anyway at this moment, so simplify that instead.
* To be able to deserialize metadata we need to include ":core:deserialization".
* Use per-fragment string tables.
* Read file names from strings instead of file names list.
wrongwrong