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.
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
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
Previously they were skipped, and this was an incorrect optimization:
even if super class implements the interface too, this doesn't mean
that virtual adapters provided by that interface are inherited
by non-exported subclass that needs them;
for example, this doesn't happen when the super class is exported
(i.e. Obj-C class is not created at runtime).
Remove incorrect optimization instead of making it more sophisticated,
because it is useless anyway.
^KT-46431 Fixed
This method can be useful when overriding a throwing Kotlin method in
Swift or Obj-C. In this case, a user can call asError to wrap Kotlin exception
to (NS)Error and then throw it to Kotlin, which will unwrap it back.
^KT-45127 Fixed
Mark Mann