... 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
This commit includes the basic Java stubs generation infrastructure and
the corresponding tests. The main entry point is called
Kapt4StubGenerator. Calls to it from production code will be added in a
separate commit.
#KT-51982
Some native test dependencies were excluded from JPS import of `:kotlin-atomicfu-compiler-pligin`
Merge-request: KT-MR-11477
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
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
PsiRawFirBuilder#visitScript didn't work because it didn't
have a configurator
Now FirScriptConfiguratorExtension split into two parts:
* File
* Script
^KT-60728
Atomicfu compiler plugin supported transformations for K/N:
* atomic properties are replaced with volatile properties and all the operations are delegated to native atomic intrinsics
* atomic arrays are replaced with kotlin.concurrent.Atomic*Arrays
* all other features available on JVM are covered as well (custom atomic extensions, delegated properties, debug tracing)
See (KT-58358, https://github.com/Kotlin/kotlinx-atomicfu/issues/261)
Merge-request: KT-MR-11253
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
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.
Alexander Udalov