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
This annotation leads to conflicting overloads error supression,
in case where several function with the same argument types,
but different argument names are inherited from ObjC class.
We need to implement it in both K1 and K2 to make the IDE experience
better.
But the annotation itself wouldn't be available in K1.
^KT-61323
Previously, when an Objective-C library had an unused Objective-C
forward declaration (`@class` or `@protocol`), cinterop tool didn't
include it into the resulting klib at all.
This led to a subtle bug (KT-64105). One Obj-C library has unused
Obj-C forward declaration, and another one depends on the first and
uses this forward declaration, e.g. as a function result type.
When building the first cinterop klib, this forward declaration is not
added to `includedForwardDeclarations` in the klib manifest (the
compiler uses this property to decide whether to synthesize the
corresponding class).
When building the second cinterop klib, the forward declaration is not
added to its manifest either, because it is located in the dependency
(and therefore should've been included there).
As a result, the forward declaration is included nowhere, and any
attempt to use it in Kotlin fails, including calling the function from
the second lib.
This commit fixes this bug by including even unused Objective-C forward
declarations, which is consistent with any other kind of declarations
and seems more natural.
^KT-64105 Fixed
Objective-C has a special type, "instancetype". Generally, it is a type
that matches the method receiver type. So, if `Foo.foo` method returns
`instancetype`, then `Foo.foo()` would be of type `Foo`, while
`Bar.foo()` would be of type `Bar` (where `Bar` is a subclass of `Foo`).
Surprisingly, `instancetype` can be used not only as a return type, but
also somewhere inside a return type. cinterop wasn't ready for this.
This commit expands implementation of `instancetype` in cinterop to
cover more cases.
^KT-59597 Fixed
It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
Move K/N dependencies handling logic into gradle plugins:
`NativeDependenciesDownloader` is instantiated in
`:kotlin-native:dependencies` and provides a single configuration that
contains all directories with the dependencies. The configuration has
a variant for each target.
`NativeDependencies` is instantiated by projects that require native
dependencies (i.e. previously used to depend on
`:kotlin-native:dependencies:update`). This plugin creates a configuration
that by default depends on `:kotlin-native:dependencies`. Its extension
provides `llvmDependency`, `libffiDependency`, `hostPlatformDependency`,
`targetDependency()` to depend on the parts needed for the project and
provides accessors `llvmPath`, `libffiPath`, `hostPlatform` that are
safe to use during configuration time, but which do not automatically
resolve those dependencies.
`llvmDir`, `*LibffiDir` properties on `:kotlin-native` are removed
completely, as their use is replaced by `NativeDependencies`. As a
consequence, `evaluationDependsOn(":kotlin-native:dependencies")` is
also gone.
All direct dependencies on `:kotlin-native:dependencies:update` are
replaced with dependencies on specific parts via `NativeDependencies`
Building with macOS gave the linker warning
`ld: warning: ignoring duplicate libraries: '/Users/foo/.konan/dependencies/apple-llvm-20200714-macos-aarch64-1/lib/libclangEdit.a'`
Remove duplication from the build script to get rid of the warning.
Co-authored-by: Dave MacLachlan <dmaclach@gmail.com>
Since Xcode 15 the iconv APIs operate on an opaque type __tag_iconv_t* instead of
void*. This causes a runtime exception in older Ktor versions which
depended on iconv.
^KT-62286
Now (mostly after 3f3f6eb) cinterop adds ExperimentalForeignApi to all
Kotlin declarations it generates from C and Objective-C libraries,
except for the platform libraries.
This commit changes the KDoc for ExperimentalForeignApi to reflect that
change.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations by default. This commit implements adding the annotation.
Nested declarations don't get the annotation, because they inherit the
opt-in requirement from the enclosing classes implicitly.
The annotation is not added to platform libraries, as intended. See
previous commits.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations by default. To make this possible to implement in a
non-intrusive manner, this commit enables adding annotations to some of
the existing Stub IR nodes.
After that, one can add annotations to all generated declarations with
a simple post pass.
^KT-58362
cinterop tool should add ExperimentalForeignApi to all generated
declarations by default. This commit supports this annotation in
cinterop intermediate representation -- Stub IR.
^KT-58362
It disables adding `ExperimentalForeignApi` opt-in to declarations
generated by cinterop.
Main use case is platform libraries, which are not supposed to have this
annotation. Applying the flag to user cinterop libraries is discouraged
and effectively means opting in.
^KT-58362
Include new project as build logic included build. Such change will
allow us to start migration into build convention plugins by splitting
buildSrc logic into subprojects.
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
For a Kotlin wrapper of an Objective-C object, this functions zeroes
and releases the strong reference from the Kotlin wrapper to the
Objective-C object.
Usually, such a release happens only when the Kotlin wrapper is GCed.
So using this function can help that happen sooner.
^KT-59134
Before this change `./gradlew help` (with native enabled)
Created immediately: 1322
Created during configuration: 1541
after this change:
Created immediately: 596
Created during configuration: 1509
To know more about configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
`staticCFunction` is used a few times in this module, and it uses
kotlin-reflect to inspect the lambda parameter, which is only possible
for class-generated lambdas.
This is needed to enable indy lambdas in the project.
* @ExperimentalForeignApi for all declarations that operate on
unmanaged memory (i.e. pointers and references)
* @BetaInteropApi for the rest of the interoperability declarations,
namely Swift/CInterop-specific interfaces and convenience-functions
### Implementation details
* Some typealiases are not marked explicitly because it crashes the compiler,
yet their experimentality is properly propagated
* License header is adjusted where it previously had been existing
* Deprecated with ERROR interop declarations that are deprecated for more than
two years are removed
* WASM target interop declarations are deprecated
* Deliberately make Boolean.toByte and Byte.toBoolean foreign-experimental to scare
people away
^KT-57728 fixed
Merge-request: KT-MR-9788
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Alexander Shabalin