Move metadata extension with property order from kotlinx.serialization to core
After fix of KT-54792 properties will be deserialized in declaration order
if corresponding class was compiled with modern compiler. But this order
is needed for kotlinx.serialization for binaries compiled with any
kotlin compiler >= 1.4. Since we don't plan to add any extension points
into (de)serialization into FIR, we need to take into account existing
metadata extension from kotlinx.serialization in compiler itself
^KT-57769 Fixed
It affected the changed test in the following way: "strict metadata
version semantics" is a flag which is written to the .kotlin_module file
between the version and the protobuf data, see `ModuleMapping:73`. But
flags are written only for Kotlin 1.4+, i.e. if `isKotlin1Dot4OrLater`
returns true. So in the test, the flag was not written, thus we did not
detect that the module actually has incompatible metadata, and thus
incorrectly did not report an error.
It also has an effect that version requirements for nested classes will
now be written correctly to protobuf with metadata version 2.0+.
With this flag we can distinguish enum classes that have `entries`
property in the compiled bytecode (see `LanguageFeature.EnumEntries`).
This is needed to be able to understand in the frontend whether
`entries` can be called for that class. For Native and JS, this is
currently not possible even if the feature is enabled, but the class
was compiled with disabled feature.
^KT-53929 Fixed
In DeserializedClassDescriptor and MemberDeserializer, only the
`contextReceiverTypeList` field was used, and not
`contextReceiverTypeIdList` which is used when `-Xuse-type-table` is
enabled. The convention is to use a bunch of utilities declared in
`protoTypeTableUtil.kt` which deal with both methods of reading types.
Also, simplify the deserialization code in FIR (which was correct for
some reason).
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
KotlinCommonMetadata can be used to inspect .kotlin_builtins and
.kotlin_metadata files. It's in an internal package for now, but might
be published once the API is finalized.
If serialized metadata version has evidently incorrect size the module
should be marked for rebuild prior to reading serialized version.
#KT-42194 Fixed
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.
This will be used in the compiler starting from 1.5.20 instead of the
currently used approach of looking for the single value parameter of the
primary constructor. The problem with the current approach is that
primary constructor can be private (since 1.4.30) and the property could
always be private. Relying on private declarations from metadata is
dangerous; for example lazy IR doesn't usually create stubs for private
declarations, and it didn't create stubs for private inline class
constructors before b5f9b1df, which led to the problem reported in
KT-44723.
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
- Remove klib dependency on metadata and uniqID
- Refactored proto format to make it more effective and compact
-- Use special encoding for some types of data (coordinates, flags, types)
-- Remove symbols table
-- Use packed proto list if it is possible
- Remove extension from metadata
- Remove special ids for function interfaces
- Fix klib IO
- Fix incremental cache
- General code clean up
Dmitriy Novozhilov