Because `public JvmTypeExtensionVisitor` was removed, a new place for `const val PLATFORM_TYPE_ID`
is required. It is logical to place it as a some kind of constant for Km node;
however, because it is platform-specific, there is a need for an empty
`KmFlexibleTypeUpperBound.Companion` in metadata common sources
and `public val KmFlexibleTypeUpperBound.Companion.PLATFORM_TYPE_ID`
extension in kotlin-metadata-jvm sources.
See also: KT-63156
This includes APIs such as:
- Visitors API
- Obsolete KotlinClassMetadata reading and writing API
- Extension and extension visitors API
- Flags and `class Flag` (a reduced version of it was moved to test sources)
- Various utility methods
Extensions mechanism got reworked with the removal of public visitors; it is
completely internal now with special accessors in kotlinx.metadata.internal
package.
Since `var KmClass.flags` is internal now (instead of being deprecated), special
utility functions with the name `_flagAccess` were added to internal package
for testing purposes.
^KT-63156 Fixed
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
same as they were in K1 (see KSerializerDescriptorResolver): internal for
final classes and public for non-final.
Unfortunately, there are no Klib API dumps tests in the compiler, so I tested manually.
#KT-64124 Fixed
for cases when the version requirement cannot be read correctly (missing from the table).
It usually happens when we read the inner class' old metadata, which stored everything
in the outer class' table.
Fixes #KT-60870
Merge-request: KT-MR-13337
Merged-by: Leonid Startsev <leonid.startsev@jetbrains.com>
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
If a serializable class has generic type parameters, its serializer is not an object
and has a specialized constructor. This constructor was public in K1 and should
be public in K2 so it can be called from other serializable classes
(in case class is e.g., part of sealed hierarchy).
#KT-63402 Fixed
This diagnostic used an incorrect type for rendering (outer class type instead of a property type)
and didn't expand type argument of `KSerializer`.
Also add an additional test case for generic parameters.
#KT-63570 Fixed
To be more consistent with K1, certain diagnostics should be reported
not on the whole properties' types, but on type arguments inside them.
Note that there is still a difference with K2 because K2 reports on a type argument
including its annotations, while K1 used KtTypeReference.typeElement.
IMO, K2 conveys the same or better meaning here, so I am willing to leave this
difference instead of providing PositioningStrategy.
#KT-53861 Fixed
because WARNING versions of them were already released at some point.
The following declarations were not promoted and have to be promoted later:
- KmProperty.hasGetter, .hasSetter
- Deprecations from readStrict/readLenient/write() rework
#KT-63157 In progress
Properly set up dom-api-compat dependency for JS IR tests. Since this dependency is added
automatically for every Kotlin/JS library, it should be present during tests just as stdlib.
As a result, tests for serializable enums were changed since 1.6.0 runtime does not require enums to be explicitly serializable.
This helps to completely get rid of Visitors API during reading and writing
of the JVM metadata.
Note: Klib writers still use .accept and left for future refactorings.
See also #KT-59442
Rewrite Readers.kt and Writers.kt to avoid using
Visitors API
Align KotlinCommonMetadata/KotlinModuleMetadata API with
KotlinClassMetadata one (it is necessary for restructured reading/writing)
#KT-59442 In Progress
For annotations defined in Java, IrProperties do not contain initializers in backing fields,
as annotation properties are represented as Java methods.
Therefore, it is not possible to use initializer values as default values for constructor parameters.
However, K2 stores default values in annotation's constructor parameters,
so it is possible to fix this issue if they're properly transfered to the IR
and inspected in JvmAnnotationImplementationTransformer
#KT-47702 Fixed
#KT-47702 tag fixed-in-k2
By ignoring type parameters. Since type parameters in annotations are a
very limited feature, their sole use is to be able to specify them as
KClass argument: annotation class Foo<T: Any>(val bar: KClass<T>).
Since we can encounter type param only as a KClass type argument (and
never as a property type), simple approach of ignoring them works fine.
In that case, since we simply copy property types to synthetic
implementation class, its properties in IR start look like this:
annotation class FooImpl(override val bar: KClass<T of Foo>). This IR
seems to be not completely correct, since FooImpl.bar type contains T of
Foo param, which is out of its scope. However, so far I didn't
encounter any problems with this during testing and after MR discussion
this approach has been considered possible.
#KT-59558 Fixed
#KT-59036 Fixed
Most of the declarations are made public as-is, except for some reader implementation details
and MetadataExtensions.INSTANCES.
Also added missing delegation in KmDeclarationContainerVisitor.visitExtensions
#KT-59182 Fixed
SerializerFactory is an implementation detail for Kotlin/JS and Native:
it should be added as a supertype to a companion object of certain serializable classes
and `serializer(vararg KSerializer<*>)` function from it should be implemented.
Existing implementation added the supertype, but did not add proper override to FirClass
of a companion, which led to various warnings and errors like 'Abstract function 'serializer' is not implemented in non-abstract companion object'.
Also implemented the addition of SerializerFactory supertype to user-defined companions within @Serializable and @MetaSerializable when necessary.
Also set up proper box tests for FIR+Kotlin/JS combination.
#KT-58501 Fixed
#KT-59768 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
Introduce extensions for KmNodes to work with various modifiers instead of old Flags.SOMETHING.invoke(flags).
Provide Visibility, Modality, and Kind enums.
Introduce KmPropertyAccessorAttributes to replace KmProperty.getterFlags and KmProperty.setterFlags.
Deprecate nodes constructors which take flags but not flags itself (yet).
Adapt KotlinP to changes.
#KT-59440 Fixed
- Write now returns result (Metadata or ByteArray) directly without re-wrapping it;
- annotationData/bytes is private to avoid unsoundness if external client corrupts it;
- .toXxx() do not throw exceptions anymore and deprecated. Exceptions are thrown only from read/write;
- Instead of toXxx(), properties like .kmClass should be used instead. They're initialized eagerly and return a view without copying.
- KotlinClassMetadata.Unknown is now a data object, as no useful information is exposed
#KT-59365 Fixed
This commit adds missing pieces for the puzzle:
Annotation instantiation feature uses IrProperty's initializer to instantiate
properties from other modules that have default values which weren't
specified on call site.
To support this feature properly, Fir2IrVisitor should fill LazyIrProperty's
backing field initializer with information from Fir.
To get this information into Fir, FirMemberDeserializer should be able to read
it from KotlinJvmBinaryClass with AnnotationLoaderVisitorImpl. (klibs are unsupported for now)
There's a catch with enum entries references: we can't access session.SymbolProvider to resolve it
because we're still at the deserialization stage, and it can cause StackOverflow if enum is nested in the
same class (see RequiresOptIn.Level). To mitigate this, a new FirEnumEntryDeserializedAccessExpression is produced
instead; it is later replaced with the correct reference in the Fir2IrVisitor.
^KT-58137 Fixed
Also add test to loadJava folder with annotations default values that
verifies metadata loading
Otherwise, findTypeSerializerOrContextUnchecked works incorrectly when analyzing code
compiled with Kotlin 1.7.20 and serialization 1.4.1.
#KT-57704 Fixed
Return null instead.
Such behaviour is needed to support cachedChildSerializers logic.
Since this field creator doesn't provide genericGetter (because it's
static),
type param serializer can't be retrieved, and the whole contextual
serializer shouldn't be cached.
#KT-58067 Fixed
Creation of this property in the SerializerIrGenerator.<init> can lead to
a 'Serializer not found' internal error when generator is applied to a fully-customized external serializer.
In that case, generator is still created, but none of the generateSave/Load functions are called,
so cacheableChildSerializers(Property) is not necessary.
#KT-57730 Fixed
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2260
These declarations should not be visible to users (and therefore are not added to FIR),
but plugin itself can reference them in already compiled serializable classes,
and therefore they should be available in metadata:
- synthetic deserialization constructor
- static write$Self function
See also:
^KT-55885
- Replace !! with requireNotNull()
- Add try/catch to wrap all other exceptions (mainly protobuf parser ones)
- Add tests for malformed input for both read and write
- Hide InconsistentMetadataException from public API
- Replace its external usages with IllegalArgumentException
- Add IrPluginContext to JvmBackendContext, so plugin intrinsics can
reference external functions properly.
- Do not use module.findClassAcrossModuleDependencies as Descriptor API does not work for FIR.
- Add asm listing tests in serialization plugin for K2
- Remove Delegated.kt asm listing test as we have similar test in boxIr group.
#KT-56553 Fixed
Because SerializationJvmIrIntrinsicSupport does not instantiate annotations yet,
this info could be lost. As a workaround, it is possible to call Companion.serializer()
functions instead of direct serializer instantiation, as they are plugin-generated
and correctly handle annotations.
Note that for some cases (enums & interfaces) this WA is not enough, so additional work
is needed later.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2179
as it may have no primary constructor (only actual class has it).
Refactor & rename Fir2IrGeneratorUtils.kt as having 'Fir' in stacktrace
when actual K2 compiler is not used is very confusing.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2134
#KT-55683 Fixed
Update changelog for kotlinx-metadata-jvm 0.6.0, add migration guide, and actualize ReadMe.md
Document releasing process
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
Merge-request: KT-MR-8206
Merged-by: Leonid Startsev <leonid.startsev@jetbrains.com>
Name check was forgotten during refactoring, so any user function with
matching signature could be overwritten by the plugin, while correct
function would not have body.
#KT-55682 Fixed
of the class used in @UseSerializers: Use methods to receive
full list of supertypes.
K1 supertypes() call returned all supertypes, while
IrClass.supertypes and FirClassSymbol.resolvedSuperTypes return only immediate ones.
This lead to a difference in behavior between K1 and K2, and regression
after plugin backend was rewritten from descriptors to IR.
#KT-55340 Fixed
as ISE is more appropriate exception for validation.
Improve SerializerClassLowering.runPluginSafe so precise IrClass
where plugin have failed can be reported for non-fatal errors.
#KT-55296 Fixed
write$Self in K1 is created only on JVM, so we need this check to avoid
creating IR function without original descriptor — it will lead to various
bugs in JS and Native, such as superclass properties missing from output
when super.writeSelf is not found in descriptor.
Fixes #KT-55180
K2 plugin API has a limitation that meta annotations from plugin predicates
can't be used on nested annotations because their resolve process includes supertypes
resolve, that can be affected by the plugin itself. Therefore, @MetaSerializable
can't be applied to nested annotation classes in K2, which is reflected by
this diagnostic.
For old FE, diagnostic is lowered to WARNING with deprecation message.
- Add BCV to root project to commonize version
- Remove BCV from kotlinx-metadata-klib as it is not necessary for now
- Remove obsolete entry from kotlinx-metadata apiDump
- Add dependency from :kotlinx-metadata-jvm:check to :kotlinx-metadata:check so TC build can verify integrity of API dumps in both projects
Leonid Startsev