The module is configured to run a bunch of test suites defined as API pairs. Currently those are `CURRENT API` – `CURRENT IMPL`, `CURRENT API` – `1.9.20 IMPL`, `1.9.20 API` – `CURRENT IMPL`
^KT-61860 In Progress
based on the regular compiler tests infrastructure, but adding
directives that can customize the definition from testdata.
So far only default imports and provided properties are supported, but
the infrastructure is easily extendable to other customizations.
Another limitations that provided properties are not supported for
the black box tests - the constructor parameters computing code
should be adapted to support it.
Note: in order to pick up the customized definition, the script files
should have an extension .test.kts
This commit includes:
1. New subproject :tools:kotlinp-klib that contains the facade for
rendering the metadata in "kotlinp" format given just
KlibModuleMetadata
2. A tool for computing (external) IR signatures that are not directly
available in metadata: KlibKotlinpExternalSignatureComputer
^KT-62340
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
The "common" subproject keeps only backend-neutral logic and depends
only on :kotlinx-metadata library. It takes the name of the former
project - :tools:kotlinp
The "jvm" subproject depends on the "common" one and also depends
on :kotlinx-metadata-jvm. It gets the new name - :tools:kotlinp-jvm
There is a lot of touched files in this commit. The majority of them
is just moved files (tests, test data, etc).
Only the following files were actually modified:
.space/CODEOWNERS
build.gradle.kts
libraries/tools/abi-comparator/build.gradle.kts
libraries/tools/kotlinp/build.gradle.kts
libraries/tools/kotlinp/jvm/build.gradle.kts
plugins/kapt3/kapt3-compiler/build.gradle.kts
settings.gradle
^KT-62340
This change adds a library with cinterop that has XCTest wrapper around
Kotlin/Native tests (that are @kotlin.test.Test marked methods).
This library can be compiled with either test code using the option
`-produce test_bundle` to make a loadable test bundle or used inside
the existing ObjC/Swift tests if compiled to a framework.
The basic idea is to make XCTest be able to resolve separate test cases
and correctly show them in test reports. This was achieved by wrapping
test cases with dynamically created invocation methods. Test listeners
are integrated with XCTest Observation to make it possible to have
the same ability to report with GTest or TeamCity logging.
Gradle build files use MPP Gradle plugin and use a bootstrap version
of K/N. Property `kotlin.native.home` was moved to the kotlin-native
subproject to not override this project's K/N distribution, that is
being used by the KGP with the same property.
This is a part of ^KT-58928
Merge-request: KT-MR-13268
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
- Lincheck is compiled with JDK 11 and the `low-level-api-fir` module is
based on the JDK 8 toolchain, so we need to add a new module with a
JDK 11 toolchain to support Lincheck tests. We cannot bump
`low-level-api-fir` to JDK 11 because `low-level-api-fir-for-ide`
requires it to be based on a JDK 8 toolchain.
- Using a Gradle test suite is unfortunately not an option, because
`low-level-api-fir-for-ide` will think that the whole
`low-level-api-fir` module is compiled with JDK 11 if just a single
test suite has this toolchain.
^KT-62136
Add a sir-compiler-bridge module that adds Kotlin and C bridges
for SIR. As SIR is still WIP, the module accepts `BridgeRequest`
instances instead of SIR elements.
New modules 'sir', 'sir-passes', and 'sir-analysis-api' were added under
'native:swift' for creating and manipulating Swift IR elements.
* `sir` contains the implementation of Swift IR.
* `sir-analysis-api` contains translation from Analysis API to SIR.
* `sir-passses` contains transformation passes.
This groundwork will allow to progress with the Swift IR.
The commit removes all the KLib resolution logic,
now Analysis API Standalone clients need to provide all the KLib
list directly.
The resolution logic was removed as too error-prone and requiring compiler configurations.
Kotlin Gradle plugin can provide a full set of required KLibs,
so if a client is a Gradle plugin, this should not be an issue.
Probably, some fancy API which will explicitly perform all KLib dependency searches
should be introduced in the future (KT-63395)
^KT-63126 fixed
Add an ability to publish kotlin-native-compiler-embeddable.jar and
sources to maven. Adds necessary for that sourcesJar and javadocJar
tasks. Note that Native distribution uses this jar without a version postfix.
Also cleaned up the obsolete backend.native publication and renamed
project to match its name.
Merge-request: KT-MR-12974
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
cristiangarcia