Xcode shows a warning from the iOS framework header when using enums in Kotlin. This resulting framework header has conflicting nullabillity on compareToOther::
@protocol StdlibComparable
@required
- (int32_t)compareToOther:(id _Nullable)other __attribute__((swift_name("compareTo(other:)")));
@end;
@interface StdlibEnum : KotlinBase <StdlibComparable>
- (instancetype)initWithName:(NSString *)name ordinal:(int32_t)ordinal __attribute__((swift_name("init(name:ordinal:)"))) __attribute__((objc_designated_initializer));
- (id)clone __attribute__((swift_name("clone()")));
- (int32_t)compareToOther:(StdlibEnum *)other __attribute__((swift_name("compareTo(other:)")));
@property (readonly) NSString *name;
@property (readonly) int32_t ordinal;
@end;
This is the warning from Xcode:
Conflicting nullability specifier on parameter types, 'nonnull' conflicts with existing specifier '_Nullable'
As you can see the StdlibComparable has the _Nullable keyword, but the implementation of StdlibEnum does not have the _Nullable keyword.
Does it produce any real issues beyond a warning?
No it does not, but a framework shouldn't contain any warnings. It isn't exactly a quality mark that the first thing you see is a warning :)
We are also running into this issue and we now have this warning over 80 times in our project.
This makes it hard to see other warnings in the project.
To workaround the issue add -Xcc -Wno-nullability to "Other Swift Flags" in "Build Settings".
(If you import Kotlin framework to Objective-C code, then also add -Wno-nullability to "Other C Flags).
To workaround the issue add
-Xcc -Wno-nullabilityto "Other Swift Flags" in "Build Settings".(If you import Kotlin framework to Objective-C code, then also add
-Wno-nullabilityto "Other C Flags).
Why not to fix it?
To workaround the issue add
-Xcc -Wno-nullabilityto "Other Swift Flags" in "Build Settings".(If you import Kotlin framework to Objective-C code, then also add
-Wno-nullabilityto "Other C Flags).
Thanks, that helps until it is resolved in Kotlin native.
Fixed in 1.3.41 and 1.3.50.
Most helpful comment
No it does not, but a framework shouldn't contain any warnings. It isn't exactly a quality mark that the first thing you see is a warning :)