Change package, artifact group, artifact name, and Gradle module name to
kotlin-metadata and kotlin-metadata-jvm, respectively.
In Kotlin 2.0, kotlin-metadata-jvm library is promoted to stable, and is
a part of Kotlin distribution now.
Note that kotlinx-metadata-klib is left with org.jetbrains.kotlinx group, artifact name and package
because -klib part is considered not stable and for internal use. Since it is still published via Sonatype,
it should have kotlinx group. Therefore, it will have both classes from kotlin.metadata and kotlinx.metadata packages. This is not a problem, because we already had kotlinx.metadata split package between -jvm and -klib before.
#KT-63219 Fixed
Separate class allows encapsulating comparison, equality, and structure of version parts.
It also makes more sense from API standpoint than plain `IntArray`.
To make sure that the correct version and flags are preserved during metadata transformation,
they are now stored inside KotlinClassMetadata.
Such change also makes it possible to make write() a member function of KotlinClassMetadata, further simplifying API.
Also, it allows tracking whether readStrict or readLenient was used to read metadata and prohibit writing accordingly.
Also provide transform() method as a shortcut for readStrict+write.
Related to: #KT-59441
In strict mode, an exception will be thrown when inconsistent metadata is encountered. In lenient mode, the reader will attempt to handle the inconsistent metadata by ignoring certain inconsistencies. This is a solution to a problem of reading metadata 'from the future' that is not allowed by default, but desired in certain cases. See updated ReadMe for details.
Also fix problem with Strict Semantics flag.
#KT-57922 Fixed
#KT-59441 Fixed
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
... for non-const properties.
The meaning of this flag for non-const properties is in reality not
well-established, and it can vary from one release to another. In
particular, it's different in K2.
This commit has two parts:
1) The test (added in 5891617674) about clinit is changed. Original
motivation was to check that presence or absence of `<clinit>` is not
a part of the ABI. However, in addition to that, the test also
involuntarily checked that the aforementioned "hasConstant" flag for
the property y/Object.y is the same in both cases (which I believe
was not the intention) because these tests check that Kotlin metadata
is _exactly the same_ after applying jvm-abi-gen. So I've changed it
to be more straightforward: one version declares an obvious constant,
while another declares an obvious non-constant. After this change,
the test started to fail (even on K1) because the value of the
"hasConstant" flag was different between two versions.
2) Remove "hasConstant" flag for non-const properties when transforming
metadata via jvm-abi-gen. This fixes the test and assures it won't
fail when the project is migrated to LV 2.0.
#KT-60849 Fixed
Embedding published version while using source one can lead to runtime errors like NoClassDefFound
if a new (not yet published) declaration was used in implementation.
Flag, Flag constants, Flags typealias, flagsOf() function, and
Flag accessors in nodes (such as KmClass.flags, KmClass.jvmFlags, KmProperty.setterFlags, etc)
#KT-59440
To make these tests behave closer to kapt, since kapt is the primary use
case for the light analysis mode.
AbstractLightAnalysisModeTest compares the text dump of bytecode
obtained with full analysis and light analysis, removing things like
anonymous/synthetic entities. In the light analysis mode anonymous
objects in supertypes are always approximated, and in the full analysis
mode they are always present as is in signatures. So we're transforming
the text dump in the same way, by approximating anonymous objects in
signatures (more precisely, in return types of methods and fields) to
the supertype.
To be cacheable relocated shadow jars should not include manifest with
build number. Instead, we repack relocated shadow jar in default jar
task with proper manifest.
If a class is not referenced by the ABI class file, its InnerClasses
entry should only be kept if it's the current class or a descendant
of the current class.
Sonya Valchuk