Shipping C/C++ headers in the Swift toolchain

Development C++ interoperability
,
1

The swift/bridging header defines C/C++ annotations that are recognized and used by Swift's ClangImporter for interop. This header file currently ships with the toolchain in the <toolchain>/usr/include/ subdirectory, which is part of Clang's default search paths for Apple-built toolchains, but not for OSS toolchains distributed via Swiftly/swift.org.

To make this behavior consistent, I'd like to propose shipping this header file in a separate "Swift resource directory", which would consist of the following changes:

  • (swiftlang/swift) move the installation destionation for the swift/bridging header from <toolchain>/usr/include/ to <toolchain>/usr/lib/swift/include, which is the location of the Swift resource directory.
  • (swiftlang/llvm-project) add <toolchain>/usr/lib/swift/include to Clang's default search paths
  • (swiftlang/swift-installer-scripts) adjust package manifests to include the new resource directory.

The addition of this default search path to the OSS Swift toolchain's Clang will allow that toolchain to resolve #<swift/bridging> without explicitly adding that search path to the build invocation.

Note, however, that this will not affect C/C++ compilers outside of the Swift toolchain. In particular, upstream Clang will still not be able to resolve #include <swift/bridging> without adding an explicit search path (which is the status quo). Those toolchains will still be able to derive that directory relative to Swift-Clang’s own resource directory, i.e., $(swift/toolchain/clang -print-resource-dir)/../../swift/include .

The motivation to behind moving the directory from <toolchain>/usr/include to <toolchain>/usr/lib/swift/include is to ship it alongside the rest of the toolchain-specific files. We already ship a number of header files in other subdirectories of <toolchain>/usr/lib/swift to support the toolchain, and as well as Clang’s own resource directory under <toolchain>/usr/lib/clang/<version>/ .

I'd love to hear your thoughts and suggestions about this. Thank you!

1 Like
2

I would rather that we do not do this; the resource directory is already stuffed with a lot of content that we should be working to remove from there. Windows and macOS already do this to a certain extent and it causes some confusion.

This would be reasonable - but we could also change it to add ../include to the default search path as an alternative.

The content in the resource directory in clang is pretty different. The (clang) compiler resources are generally for exposing the intrinsics. I don't think that the macros are exposing intrinsics, they are just providing convenience macros for the attributes.

3

Huge +1 on this proposal.

I’ve encountered the exact same problem when using C++ interop in one of my cross-platform Swift packages, and even reported it separately. From my experience, this looks like a bug in SwiftPM’s current handling of the swift/bridging header search path.

For reference: