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
Currently, KAPT3 uses JDK internal API to build Java AST.
Since the API is internal, it has changed in newer JDKs.
So, for them, use reflection to access new API.
#KT-59349 Fixed
This change expanded KAPT to support a new param
'fileAccessHistoryReportFile', which reports all the classes used during
annotation processing into a file, in the form of a list of URIs.
This is useful for build speed improvements described in https://engineering.fb.com/2017/11/09/android/rethinking-android-app-compilation-with-buck/.
Essentially, using the list of used classes, we can compile only
the dependencies that are really affected by the developer's
code changes and improve Kotlin build speed.
^KT-52853
This commit provides a small fix in the code of a native test runner so that JDK11 is not required and removes the JDK11 target for the atomicfu-compiler-plugin.
Fixes KT-61293
Merge-request: KT-MR-11757
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Originally it used list of declarations, which is incorrect, because
some constructors may be contributed by compiler plugin. And those
constructors will be contained only in scope
This prevents `FirConflictsExpressionChecker.kt`
from missing conflicting local functions. It used
to due to inconsistencies in assigning `<local>`,
and this commit makes it a bit more
straightforward.
The change in KtClassTypeQualifierRenderer
prevents `FirOverrideImplementTest.testLocalClass`
from failing in `intellij`. It didn't fail for
callables, because `KtCallableSignatureRenderer`
doesn't try to render packages.
^KT-59186 Fixed
To check that boolean "is" prefix is treated correctly, and Unit return
type is not translated to void. `@Deprecated` annotations are added just
so that the `$annotations` methods would also be generated.
In normal circumstances, it leads to the field `c$delegate` NOT being
generated (see KT-39054). However, it's not the case in kapt in any
mode:
- In the old JVM backend, this optimization is not supported.
- In JVM IR, property initializers are missing in light analysis, so
backend cannot figure out that this property is optimizable.
- In kapt4, backend is not being run, and symbol light classes do not
have information about this optimization.
Overall it doesn't matter much which stub is generated here because the
field is private, the test is added just in case.
Also adds rendering of @Metadata annotations in Kapt3 and Kapt4 tests
(currently disabled for a few tests).
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
* `nativeTest` task now allows to provide compiler plugins that may be enabled during test compilation
* test sets for JVM and K/N backends are equal
KT-60800 describes all the issues with native tests that were solved in this commit.
Co-authored-by: Dmitriy Dolovov <Dmitriy.Dolovov@jetbrains.com>
Merge-request: KT-MR-11401
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
... 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>
Alexander.Likhachev