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>
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.
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>
Adds convention plugin instead of sources inclusion
inside the buildSrc, effectively reducing the amount
of the code to be compiled in buildSrc.
Merge-request: KT-MR-8898
To avoid adding unnecessary included categories to index, we need
to track their location. Also, we can't just implement TypeDeclaration
interface because category is not a type. Thus, we extract `location`
property from TypeDeclaration to LocatableDeclaration and implement it
in ObjCCategory.
It allows to list Objective-C classes that should include
corresponding categories from the same file.
The current implementation is super-simple and slow, but
it is OK since it is not intended to be a general-purpose
solution for now.
Expanding macros such as __FILE__ or __TIME__ exposes
arbitrary generated filenames and timestamps from the compiler
pipeline which are not useful for interop and makes the klib
generation non-deterministic. This patch instead redefines
the macros to just map to their name in the properties
available from Kotlin.
Co-authored-by: Johan Bay <jobay@google.com>
Otherwise common compiler arguments which are set for all modules in the
project in `buildSrc/src/main/kotlin/common-configuration.gradle.kts`
are not applied. The most interesting of those are `-Xuse-k2` (if K2 is
enabled) and `-Xjvm-default=all`.
KotlinSourceSet now should be accessed via Kotlin project extension.
Conventions are still available, but not used inside plugins.
^KT-47047 In Progress
For some reason, libclang's indexer doesn't index categories with
__attribute__((external_source_symbol(language="Swift",...))),
so we have to additionally enumerate them explicitly.
^KT-49455 Fixed
Extract diagnostics from imported modules by instructing libclang to
serialize diagnostics to file. Then deserialize this file and use
first compilation errors in the error message.
^KT-35059 Fixed
The right way is to add something like KonanTarget.MSVC_X64, but doing
so requires changes throughout whole compiler. It would be especially
painful in HostManager, where we would need to deprecate
KonanTarget.MINGW_X64 as host. Instead we "hack" ClangArgs to compile
for x86_64-pc-windows-msvc instead of x86_64-pc-windows-gnu in JNI case.
CI may contain custom MSVC and Windows Kit installation path, so we
should support it. Things might break when machine has several MSVC
installed (at custom and default path), but it sounds more like
incorrect environment setup problem than ours.
Since LLVM for Windows is now native instead on MinGW, we have to
compile code in a different environment in case of JNI. This commits
just separates ClangArgs into two subclasses without actual behavior
changes.
Yahor Berdnikau