We export cdecl function declarations twice: for Objective-C and 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 C++
declarations visible in Objective-C++ mode. However, for this particular
problem I decided to also 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
C declarations and consume them from C++ or Objective-C++, those are the
correct declarations.
rdar://129550313
The generated thunks for functions can refer to some internal methods of
their arguments. As a result, those generated thunks should always be
after the definitions of the corresponding argument types. The printer
ordered the declarations by name, and Swift had the convention starting
types with upper case letters and functions with lower case letters.
This naming convention together with the ordering resulted in the
correct ordering in most of the cases. There were a couple of exceptions
when people diverged from the naming conventions or wanted to export
operators. This patch fixes this problem by always ordering type decls
before function decls.
rdar://129276354
The clang nodes associated with Swift's Core Foundation types can already be
represented by a pointer. The interop code does not need to add an extra
layer of indirection in those cases.
rdar://119840281
In some cases, the reverse interop generated both a forward declaration and a
definition with unavailable attribute in the C++ header. Unfortunately, the
kinds of these symbol did not match. The forward declaration was templated
while the definition was not. The forward declaration has the correct kind,
so this patch extends the printing of unavailable definitions to include the
generic arguments.
rdar://119835933
In Swift, we can have enum elements and methods with the same name, they are overloaded.
Unfortunately, this feature is not supported by C++ interop at the moment. This patch
avoids emitting the methods with name collisions to make sure the resulting header
can be compiler. A proper fix should follow in a later PR.
rdar://128162252
This fixes a compiler crash that happened when emitting a Clang header for a Swift module that declares multiple macros with the same base name and different argument names.
Swift macros are not currently designed to be exposed to C++. This teaches the compiler to explicitly mark them as unavailable in C++.
rdar://117969472 / resolves https://github.com/apple/swift/issues/69656
Extend the previous commit’s support for functions that return Never to also properly generate code for *throwing* Never functions. This is a little subtle because:
• At the SWIFT_CALL level, throwing Never functions are *not* noreturn
• At the thunk level, throwing Never functions are noreturn *only* if you’re using exceptions; if you’re using swift::Expected, they should throw
• In either case, the compiler cannot statically prove that thunks are noreturn except on the error path, so we need to add an abort() call on the success path
Swift-to-C++ thunk printing for functions didn’t really take into account Swift’s `Never` type. This type maps to `SWIFT_NORETURN`, but it also requires other tweaks to code generation, such as omitting the `return` keyword. (Removing that requires minor changes to many tests.)
Fixes rdar://124137073.
As we do with Swift structs, emit the members of extensions of Swift
enums into the corresponding C++ class. This includes exposing more of
the Optional API from the standard library into Swift.
[interop][SwiftToCxx] Ignore delayedMembers in C++
This fixes a bug where an ObjC @interface declaration is emitted for a
class that has a member that isn't emitted.
Resolves rdar://119835836
This is needed as the metadata for C++ types might not be actually emitted and thus we can't always reference it
Fixes https://github.com/apple/swift/issues/69234
rdar://117089662
This is an ABI breaking change for Windows. `WCHAR` on Windows is
mapped to `short` (`-fshort-wchar` makes it `unsigned short`). When C++
interop is enabled, `WCHAR` will be mapped to `wchar_t` which is then
mapped to `short` (or `unsigned short` if `-fshort-wchar` is specified).
Correct the mapping type to get the desired behaviour.
Consider the case of a toolchain that includes clang is being used to
compile Swift. With the current ordering, the header will be found
relative to that toolchain, which could be out of date as compared to
tip. This is the case today if eg. a 5.7 toolchain is used to build
main/5.9 as the shim header is missing a definition.
[interop][SwiftToCxx] avoid emitting ambiguous C++ overloads and emit unavailable type stubs for top level types that could not be emitted in the C++ section of the generated header
