If serialized metadata version has evidently incorrect size the module
should be marked for rebuild prior to reading serialized version.
#KT-42194 Fixed
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
Before Kotlin 1.3-M2 we didn't write `has_field` flag for constants
inside multifile classes. Now we write and rely on this when
trying to load constant initializers, which is totally fine for
binaries that were compiled with the 1.3-M2 or newer version.
Unfortunately, constant initializers will not be loaded for old binaries.
One way is to avoid relying on this flag, but then we'll get other
problems (e.g. 3345dc81fd).
Therefore, for binaries that were compiled with at least 1.3-M2 version,
we'll rely on the flag, otherwise, we won't.
Note that this change brings an incompatibility: `Array<Foo>::class`
will be seen as `Foo::class` by the old deserializer. We consider this
OK because the compiler never had any logic that relied on reading class
literal arguments correctly (otherwise it wouldn't have worked because
it could only see `Array<*>::class` before this commit), and the support
of annotations on types in JVM reflection is only available in the
upcoming 1.3 release (KT-16795)
#KT-22069 Fixed
This commit reverts 59e2101a25 partially,
leaving only the implementation of KT-25972 for JVM. The reason is that
we can't fully commit to stabilizing JS (and .kotlin_metadata) binary
metadata formats so much as to postpone any changes done to it for a
whole release year time. It's likely that we will need to update JS
metadata format incompatibly pretty soon, and with the scheme where we
can read the "current + 1" version, it'd require advancing the metadata
version by 2, which would break the nice property that the metadata
version (since Kotlin 1.4) is equal to the version of the compiler that
produced it.
See KT-25972
JVM versions are increased in order to differentiate pre-1.3-M2 .class
files where signatures mentioning inline classes were not mangled. Other
versions are increased in case something similar will need to be
detected
Already existing tests testRequireKotlinInNestedClassesAgainst14{,Js}
now check that there's no error when loading a module/class with
metadata version 1.4.0
#KT-25972 Fixed
Instead of adding new kind of types, we'll use flag to disambiguate
usual types from unsigned ones, this approach has two advantages:
- less changes in the metadata format
- it allows naturally extend format for unsigned arrays,
which will be supported later
#KT-25310 Fixed
#KT-25273 Fixed
The only client of this data is reflection, and since anonymous objects
do not have constructors in the source code, they shouldn't in
reflection as well
#KT-20442 Fixed
The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
Instead of IndexOutOfBoundsException from the protobuf internals which
was thrown when loading extension with a non-existing index out of the
list of all extensions (KT-23413)
StringTable.serializeTo was effectively only used for JvmStringTable,
but was declared in StringTable because of the usage in
DescriptorSerializer.serialize (which, in turn, was only used from JVM
codegen)
Previously, if both type and typeId messages were missing (for example,
ProtoBuf.Function.returnType/returnTypeId) because of some bug, the
behavior was unpredictable because a type with id 0 from the type table
would be returned, which could be a completely irrelevant type. This is
an incorrect situation and we should report a diagnostic instead.
Temporarily throw an exception instead, since this only affects how the
compiler works on bad metadata
Andrey Uskov