[swift-users] Annotating C APIs without changing the original header files

[Rick Mann]

I'm trying to use apinotes for this third-party C library (call it "Lib.dylib"). It has an enum lgs_error_t:

typedef enum {
    lgs_error_none = 0,
    lgs_error_invalid_handle = -1,
    lgs_error_null = -2,
    lgs_error_invalid_parameter = -3,
    lgs_error_invalid_operation = -4,
    lgs_error_queue_full = -5
} lgs_error_t;

So I wrote apinotes ("Lib.apinotes") that look like this, next to the .dylib, and part of my Xcode iOS app target:

Enumerators:
# lgs_error_t

- Name: lgs_error_none
  SwiftName: lgs_error_t.none
- Name: lgs_error_invalid_handle
  SwiftName: lgs_error_t.invalidHandle
- Name: lgs_error_null
  SwiftName: lgs_error_t.nullParameter
- Name: lgs_error_invalid_parameter
  SwiftName: lgs_error_t.invalideParameter
- Name: lgs_error_invalid_operation
  SwiftName: lgs_error_t.invalidOperation
- Name: lgs_error_queue_full
  SwiftName: lgs_error_t.queueFull

But this line of code fails:

var err: lgs_error_t = .nullParameter
Type 'lgs_error_t' has no member 'nullParameter'

Am I missing something else?

> On May 4, 2017, at 16:55 , Douglas Gregor via swift-users <swift-users at swift.org> wrote:
> 
> 
>> On May 3, 2017, at 4:10 PM, Geordie J via swift-users <swift-users at swift.org> wrote:
>> 
>> Hi everyone,
>> 
>> I’m about to start on another big project with Swift on Android and would like to annotate that JNI headers as much as possible before I do: specifically I’d like to make _Nonnull and CF_SWIFT_NAME annotations to the headers found in a user's jni.h.
>> 
>> The question is: is it possible to annotate headers this without changing the original header files? Specifically I’m looking for an options that allows annotations in a separate file, probably one that is read when loading the package’s module.modulemap.
>> 
>> I’d like to distribute the annotations in a SwiftPM package that also exposes the original (hopefully annotated) headers. Up until now I’ve been using Swift to override methods in code, but this isn’t as clean or extensible and I fear it may have other (particularly performance) implications.
>> 
>> I guess the alternative would be to just maintain and distribute a modified version of jni.h with the annotations, but that would be a "last resort” option.
> 
> 
> This is the role of API notes, which you can see here:
> 
> 	https://github.com/apple/swift/tree/master/apinotes
> 
> with some rough documentation-in-source here:
> 
> 	https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp
> 
> 	- Doug
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users


-- 
Rick Mann
rmann at latencyzero.com