For a more efficient lookup of a companion with the functions of obtaining a serializer, a special annotation is added to the named companions.
Merge-request: KT-MR-11003
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Move language version settings, compiler configuration and different
flags there, and use this config everywhere in both backends instead of
GenerationState.
This will hopefully make GenerationState less of a "god object" and
remove the need to have it available everywhere, in particular in JVM IR
lowerings code, in the future.
Also, future refactorings will make it easier to inject backend-specific
behavior into common code, so that we would not need to handle support
of new features in the old backend.
The following transformations were commonized:
* generation of the transformed atomic extension signature
* building atomic array fields (arrays are now supported on both backends JVM and K/N)
* transformation of function calls on atomic array elements
* Generation and invocation of atomic extensions (the only difference is generation of synthetic value parameters)
* Changed synthetic parameters passed to the generated atomic extensions
See, KT-60528
Merge-request: KT-MR-11249
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
- make some utility functions and classes public
- split some classes into common and Kapt 3 - specific parts
- use Kapt 4-ready filtering of @Metadata annotations in tests
and base class handling:
Since in K2 we do not distinguish between script arguments taken from
the base class and provided properties, we need this extra functionality
to preserve the argument order of K1 scripts.
This is a temporary measure, since we're going to deprecate base class
usage at some point (KT-60449), so the relevant constructor arguments
should disappear too.
The following updates in the JVM/IR plugin were made:
* Lots of refactoring with preparation for K/N support: commonization of transformations.
* Improved error handling (checks for visibility constraints, appending message about usage constraints in case of an error).
* Explicit requirements for the visibility of atomic properties: to prevent leaking they should be private/internal or be members of private/internal classes.
* Fixed visibility of generated properties: volatile properties are always private and atomic updaters have the same visibility as the original atomic property.
* Volatile fields are generated from scratch and original atomic properties are removed.
* Delegated properties support is fixed (only declaration in the same scope is allowed).
* Non-inline atomic extensions are forbidden.
* For top-level atomics: only one wrapper class per file (with corresponding visibility) is generated.
* Bug fixes.
The corresponding tickets:
https://github.com/Kotlin/kotlinx-atomicfu/issues/322
KT-60528
Merge-request: KT-MR-10579
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
For interfaces with custom serializer (@Serializer(`SerializerType::class)`) now the `serializer()` function is generated in the companion so that user can get a serializer by type
Merge-request: KT-MR-11040
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
The AllOpen plugin can make private members open. But for private
properties, they can be considered stable for smart-casting if they do
not have a custom getter.
#KT-58049 Fixed
Due to possible data races configuration discovery might fail. So far,
it happened silently and we used so-called default one. This
configuration is unaware of specific implicit imports, receivers, base
class, etc. Hence, broken highlighting and navigation.
This commit introduces the following changes:
1. Having default configuration for building `FirScript` is no longer an
option. Missing configuration means error reported via exception.
2. Every configuration usage is now logged in DEBUG mode.
Troubleshooting becomes easier.
^KT-60193 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
Serialization requires an instance of the serializer, which cannot be obtained with the passed interface, abstract or sealed class.
Therefore, the specifying of such classes in `Serializable` annotation must be prohibited.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2173
Relates #KT-58036
Merge-request: KT-MR-10753
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
Problem is reproducible only when singing is enabled.
Register dependencies between publication and signing tasks.
It looks like signing tasks have same output and need to be registered
in all publications.
Error:
* What went wrong:
Some problems were found with the configuration of task ':kotlin-annotation-processing-embeddable:publishMainPublicationToMavenLocal' (type 'PublishToMavenLocal').
- Gradle detected a problem with the following location: '/Users/Shared/Projects/kotlin/plugins/kapt3/kotlin-annotation-processing-embeddable/build/libs/kotlin-annotation-processing-embeddable-1.9.255-SNAPSHOT-sources.jar.asc'.
Reason: Task ':kotlin-annotation-processing-embeddable:publishMainPublicationToMavenLocal' uses this output of task ':kotlin-annotation-processing-embeddable:signGradleCompatPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
Reproduce:
gradle :kotlin-annotation-processing-embeddable:publishToMavenLocal -Psigning.gnupg.keyName=* -Psigning.gnupg.passphrase=* -PsigningRequired=true
KTI-1282
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
The command line argument parser is using between 0.25s and 0.5s
(depending on platform) on finding annotated properties. This fix
replaces the slow kotlin reflection with java reflection, which is an
order of magnitude faster.
#KT-58183 Fixed
Sergey.Shanshin