[SR-141] Complex C header files macros are ignored

[swift-ci]

Previous ID	SR-141
Radar	None
Original Reporter	terhechte (JIRA User)
Type	Improvement

Additional Detail from JIRA

| | | |------------------|-----------------| |Votes | 4 | |Component/s | Compiler | |Labels | Improvement, ClangImporter, Macros | |Assignee | None | |Priority | Medium | md5: b0fc0ddd95381ed846f901d37e7cbbd0

relates to:

• SR-506 Problems loading C typedefs and defines
• SR-485 C macros of the form ((long long)-1) should be imported

Issue Description:

I created a simple Package in order to use X11 under Linux from within Swift:
https://github.com/terhechte/CX11.swift

However, all the convenience macros defined in the header files are not available in Swift. Examples are:

#define ConnectionNumber(dpy)   ((dpy)->fd)
#define RootWindow(dpy, scr)    (((dpy)->screens[(scr)]).root)
#define DefaultScreen(dpy)  ((dpy)->default_screen)

(from http://www.opensource.apple.com/source/tcl/tcl-87/tk/tk/xlib/X11/Xlib.h)

Here's a simple Swift example that fails because the macros are not available:
https://github.com/terhechte/swift-x11-example/blob/Macros/main.swift

The master branch contains a working example without macros.

[belkadan]

Swift does not support arbitrary C macros, and is unlikely to. It'd be great to improve some of the macros we can import safely, but these definitely don't fall into that category.

[mxcl]

OK, I'll close this once I have updated the docs with recommendations.

[ddunbar]

I think it also might make sense to just repurpose this bug for whatever the eventual solution we want to solve this problem is. The use case is valid, so we could figure out how we are going to support it and track that here.

[05262b81-54a9-4fe1-bf6a-96f8042de10e]

I've filed SR-485 to cover a specific case that I think we can be better at:

#define NSURLResponseUnknownLength ((long long)-1)

[swift-ci]

Comment by Chris Bailey (JIRA)

It looks like we might be hitting this with lib dispatch as well trying to import DISPATCH_QUEUE_CONCURRENT which is defined in dispatch/queue.h as:

#define DISPATCH_QUEUE_CONCURRENT \
        DISPATCH_GLOBAL_OBJECT(dispatch_queue_attr_t, \
        _dispatch_queue_attr_concurrent)

which expands out to a pointer to the _dispatch_queue_attr_concurrent global object.

[belkadan]

Yep, all of the dispatch globals are shadowed in the Darwin overlay for this reason. We'll have to do something similar for the corelibs Dispatch.

[swift-ci]

Comment by Chris Bailey (JIRA)

Is there anything we (the community) can do to accelerate implementing an equivalent to the Darwin overlay on Linux?

[parkera]

On Linux, I expect there to be no overlay. Instead we will just have a module map and swift files created by the dispatch project itself. This is what we do for Foundation, and it does require that stuff in the Darwin overlay is duplicated as part of the swift-corelibs-foundation project for Linux.

[swift-ci]

Comment by Robert F. Dickerson (JIRA)

It appears that many existing and mature C libraries highly use these complex macros that the Swift compiler will have trouble being able to parse. I have seen this is many libraries like SDL2, libdispatch, etc. The solution is to write overlays in a Swift library that uses C module maps. Now, I can manually compile the overlay using clang, and have the module map link to the static library. However, I am wondering if there's a way to get the Swift Package Manager to compile the overlay (written in C) so it can be linked by the project that depends on it. I think that this approach will make it easier for consumers of the Swift libraries since the overlay can be built while the application gets built as the Package Manager compiles the dependency chain.

[swift-ci]

Comment by James Richard (JIRA)

rfdickerson (JIRA User) Looks like SPM is going to be able to compile the overlays: https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md