🍒[cxx-interop] Fix exporting cdecl Swift functions to Obj-C++ #74615
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
[cxx-interop] Fix exporting cdecl Swift functions to Obj-C++
|
@swift-ci please test |
egorzhdan
approved these changes
Jun 21, 2024
ravikandhadai
approved these changes
Jun 24, 2024
drodriguez
added a commit
that referenced
this pull request
Jun 28, 2024
Explanation: In #74516 the `SWIFT_NOEXCEPT` specifier is added to the imported Swift functions in C++ mode, but it is added after the function attributes. It seems that the tests only do `-fsyntax-only`, which seems not to catch an error like "expected function body after function declarator" when the header is used without that flag. Flip the attributes and the specifier around in the printer, and flip them in all the tests. The tests were using `%check-in-clang`, but it only checks importing as an objective-c-header. Add a parallel `%check-in-clang-cxx` to test also in C++. It uses C++17 because of some details in the imported headers and disables a warning about variadic macros that was promoted to an error and was blocking passing the tests. The clang-importer-sdk gets the minimal set of files to compile the two modified tests as C++. The files are mostly empty, except `cstddef` that imports the equivalent C header. Some modifications were needed in `ctypes.h` because the header was using features only available in C and not C++. Scope: C++ Interop Risk: Low besides the risks pointed out in #74615. Testing: The tests have been modified. Locally using the header without -fsyntax-only also avoids the error. Reviewer: @Xazax-hun Original PR: #74780
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Explanation:
We export cdecl function declarations twice: once for Objective-C and once for C++. When the code is compiled in Objective-C++ both of the declarations are visible to the compiler. The generated header did not compile, because only one of the declarations were noexcept. There are multiple possible ways to fix this issue, one of them would make only the C++ declarations visible in Objective-C++ mode. However, I decided to make the Objective-C functions SWIFT_NOEXCEPT. This approach resolves the inconsistency that broke the code when compiled in Objective-C++ mode. Moreover, Swift guarantees that those cdecl declarations cannot raise errors, so in case we only generate the Obj-C headers and consume them from Objective-C++, those are the correct declarations. Keeping both declarations will also help us identify further inconsistencies in the future.
Scope: C++ Interop
Risk: Low, however, when the Obj-C header is consumed by C++ or Obj-C++, the newly added noexcept is observable, code with SFINAE might pick a different overload. This observable change should be benign in most of the cases.
Testing: Added a regression test.
Issue: rdar://129550313
Reviewer: @egorzhdan, @beccadax
Original PR: #74516