Allow C targets to import the compatibility header generated for Swift libraries #8736
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The module map generated for the compatibility header was marked as `requires objc`. This triggers an error when importing it from a C source file. This declaration is superfluous, the compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import the current compatibility header even if it may not see any content. Let's lift this restriction. It isn't currently necessary and we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C.
…tory Emit the generated compatibility header and module map in a new `include` directory under the temporary build directory of Swift libraries. This directory can then be used as a header search path for the dependent clang targets. This replaces the previous header search strategy that used only the generated module map. This was incompatible with C source files and classic non-module textual includes. The use of a header search path should support both module imports via the module map as well as includes of the compatibility header.
xymus
requested review from
bkhouri,
bripeticca,
cmcgee1024,
daveyc123,
dschaefer2,
jakepetroules,
owenv,
plemarquand and
shawnhyam
as code owners
|
@swift-ci Please test |
|
@swift-ci Please test macOS |
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
|
@swift-ci Please test |
Also lift the macOS restriction now that swiftpm emits the compatibility header on other platforms.
xymus
force-pushed
the
compat-header-include
branch
from
e788fa1 to
c2d9f40
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
|
Is someone available to review this change? |
|
@jakepetroules do you think we need a similar change in swift-build? It appears to print the |
I think so, yeah, at least for the |
dschaefer2
approved these changes
Jul 3, 2025
marcprux
pushed a commit
to swift-everywhere/swift-package-manager
that referenced
this pull request
Jul 7, 2025
…t libraries (swiftlang#8736) Address two issues preventing a C source file to import the generated compatibility header: 1. Don't mark the module map generated for the compatibility header as `requires objc`. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C. 2. Emit the generated compatibility header and module map in a new `include` directory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets. This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header. Fixes swiftlang#7257. Follow up to swiftlang#8695.
dschaefer2
pushed a commit
to dschaefer2/swift-package-manager
that referenced
this pull request
Jul 8, 2025
…t libraries (swiftlang#8736) Address two issues preventing a C source file to import the generated compatibility header: 1. Don't mark the module map generated for the compatibility header as `requires objc`. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for `@cdecl` that is independent of Objective-C. 2. Emit the generated compatibility header and module map in a new `include` directory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets. This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header. Fixes swiftlang#7257. Follow up to swiftlang#8695.
dschaefer2
added a commit
that referenced
this pull request
Jul 8, 2025
…ted for Swift libraries #8736 (#8906) Cherry-pick #8736 to 6.2 Address two issues preventing a C source file to import the generated compatibility header: Don't mark the module map generated for the compatibility header as requires objc. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for @cdecl that is independent of Objective-C. Emit the generated compatibility header and module map in a new include directory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets. This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header. Co-authored-by: Alexis Laferrière <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Address two issues preventing a C source file to import the generated compatibility header:
Don't mark the module map generated for the compatibility header as
requires objc. This triggers an error when importing it from a C source file. The compatibility header is already printed in a way where the Objective-C code is protected behind a language check. C clients can safely import it even if they may not see any content. Plus we're adding C content to the compatibility header with the official support for@cdeclthat is independent of Objective-C.Emit the generated compatibility header and module map in a new
includedirectory under the temporary build directory of each Swift library. This directory is then used as a header search path for the dependent clang targets.This replaces the previous strategy that relied only the generated module map to resolve imports. It was incompatible with C source files and non-modular textual includes. The use of a header search path preserves the support for module imports via the same module map and supports textual includes of the compatibility header.
Fixes #7257.
Follow up to #8695.