Do not export extensions of classes that are
hidden from the generated Objective-C API.
Merge-request: KT-MR-10330
Merged-by: Sergey Bogolepov <sergey.bogolepov@jetbrains.com>
since we generate the default getter in this case in
Fir2IrDeclarationStorage.createIrProperty, so the serialized metadata
should follow the same behavior.
#KT-57373 fixed
Starting from language version 1.9, deprecation is not propagated
through overrides (see KT-47902 for more details).
As a result, after updating langauge version to 1.9 in 66544a4,
testObjCExport started to fail, because it expected the old behaviour.
This commit updates the test correspondingly.
The test relies on the fact that any name can be imported from a "magic"
package like `objcnames.classes`.
This was the case for K1, but likely won't be for K2: the compiler
should allow importing only those names that are actually
forward-declared in a cinterop library.
This commit changes the test that way. In particular, moves it to a
different task that has a cinterop dependency.
This commit supports `objcExportDisableSwiftMemberNameMangling=true`
binary option, which disables mangling for Swift names in generated
Objective-C headers, but keeps mangling for Objective-C names.
Enabling it might cause issues in some cases with actual clashes.
^KT-53638 Fixed
The original name was still left in the ObjC code for cases
such as:
```
class A(@property:ObjCName("y") @ObjCName("y") val x: Int)
```
which compiled to:
```
@interface FrameworkA : FrameworkBase
- (instancetype)initWithY:(int32_t)x __attribute__((swift_name("init(y:)"))) __attribute__((objc_designated_initializer));
@property (readonly) int32_t y __attribute__((swift_name("y")));
@end
```
This change renames the `x` ocurrence in `initWithY` which is
important in case ObjCName is used to avoid using names that
conflict with ObjC preprocessor macros.
Previous implementation of startCoroutineUninterceptedOrReturn expected
that the receiver (i.e. the suspend function object to start) of type
SuspendFunctionN (i.e. suspend function type with arity = N) is also an
instance of FunctionN+1 (i.e. regular function type with arity = N + 1)
with proper convention.
While compiler tries to achieve that (for better compatibility with
Kotlin/JVM, by generating additional supertypes and methods for classes
implementing suspend function types), this doesn't work e.g. for
implementations defined in Swift.
Fix this by adding fallbacks for cases when the receiver is not
a FunctionN+1, while keeping the fastpath for default FunctionN+1
cases.
^KT-51043 Fixed
Objective-c `@end` doesn't need a semicolon, however KMM exported header
file, for instance:
```
__attribute__((swift_name("KotlinIterator")))
@protocol MyProjectKotlinIterator
@required
- (BOOL)hasNext __attribute__((swift_name("hasNext()")));
- (id _Nullable)next __attribute__((swift_name("next()")));
@end;
```
This creates problems with some code checkers that will not expect it
there, so it seems best to remove it.
This patch adds a binary compiler argument to allow not crashing if a
suspend function is called from a non-Main dispatcher from ObjC or
Swift. This is relevant for people using the new memory model, in which
this restriction may be relaxed.
The Objective-C methods for Kotlin data class componentN methods
shouldn't have been generated in the first place -- the corresponding
Kotlin methods are required to make the destructuring work in Kotlin,
and don't help in Objective-C or Swift.
Calling them manually from Objective-C or Swift doesn't make much sense.
So now we deprecate this, in order to remove these methods from
Objective-C header completely later.
^KT-42641
^KT-49516 Fixed
The test expects to track block result lifetime in Swift, so we should
add it to the tracker.
Also fix the same problem for testReceiveBlockFromKotlinAndCall
(which didn't fail because we added the block itself to the tracker).
If a Kotlin exceptions is thrown out of a native code in ObjCExport
(when calling Swift/Obj-C method overriding Kotlin method, or calling
Swift/Obj-C block as Kotlin function type), treat this exception as
fatal and terminate the process.
This could happen if the Kotlin exception leaked from Kotlin to native
code before.
In other words, when calling Kotlin -> Swift/Obj-C -> Kotlin, if Kotlin
exception passes from the last to the first part, terminate.
^KT-50830
Add a test that checks that Kotlin Continuation wrapping Objective-C
completion handler has strong reference to it, i.e. completion handler
doesn't get reclaimed too early.
Follow-up to 4dcfd38.
With `unitSuspendFunctionObjCExport=proper` binary option,
for Unit-returning suspend functions ObjCExport now generates
completion handlers without redundant `KotlinUnit*` result parameter.
So Swift (5.5+) can import these functions as Void-returning async
functions.
^KT-47399 Fixed
Sergey Bogolepov