We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
Functions or template instantiations with Obj-C types should always be
behind a macro to make sure the interop header compiles cleanly in C++.
rdar://152836730
In the reverse interop header we generated move constructors that call
abort at runtime. This is problematic for several reasons:
* In C++14 and below some of our own generated functions like _make
ended up calling the move constructor. Those are calling abort and
also trigger unreachable code warning in newer versions of Clang.
In C++17 and up it is fine due to the guaranteed copy elision.
* Type traits are fooled and think these types are movable. As a result,
libraries could generate calls to the aborting move ctor.
This PR removes the generation of move operations. As we generate copy
operations, the compiler will not declare or define the move operations
implicitly. Whenever the user goes out of their way and try to move an
object they will get a copy instead.
rdar://150793518
The generated header did not compile due to a bug that prevented us from
referencing the correct namespaces derived from the nominal type's name
(an extension does not have a name). Moreover, we did not generate
forward declarations for the members of the extensions for classes and
enums (but we did for structs). This change also removes a workaround
that emitted String::Index as _String_Index.
rdar://153221450
These types are OK to by copied using memcpy. Previously, the generated
code assumed these types are exported swift types with all the value witness
functions.
rdar://111812577
PrintAsClang is supposed to emit declarations in the same order regardless of the compiler’s internal state, but we have repeatedly found that our current criteria are inadequate, resulting in non-functionality-affecting changes to generated header content. Add a diagnostic that’s emitted when this happens soliciting a bug report.
Since there *should* be no cases where the compiler fails to order declarations, this diagnostic is never actually emitted. Instead, we test this change by enabling `-verify` on nearly all PrintAsClang tests to make sure they are unaffected.
This did demonstrate a missing criterion that only mattered in C++ mode: extensions that varied only in their generic signature were not sorted stably. Add a sort criterion for this.
This patch introduces handling of ObjC protocols similar to how ObjC
classes work. Since this only works in ObjC++, all declarations
containing ObjC protocols will be protected by the __OBJC__ macro.
This patch results in some `_bridgeObjC` methods being exposed, we might
end up hiding those in the future, but there is no harm having them in
the interop header for the interim period.
rdar://136757913
It is really involved to change how methods and classes are emitted into
the header so this patch introduces the impression of nested structs
through using statements and still emits the structs themselves as top
level structs. It emits them in their own namespace to avoid name
collisions. This patch also had to change some names to be fully
qualified to avoid some name lookup errors in case of nested structs.
Moreover, nesting level of 3 and above requires C++17 because it relies
on nested namespaces. Only nested structs are supported, not nested
classes.
Since this patch is already started to grow quite big, I decided to put
it out for reviews and plan to address some of the shortcomings in a
follow-up PR.
rdar://118793469
Previously, when a Swift API referenced a C struct (that is not a C++
struct), we did not expose said API to C++. The reason was that we do
not have support yet for non-trivial structs (structs with ARC fields).
This patch introduces logic to determine if a C struct is trivial and
lets us expose trivial C structs from Swift to C++.
rdar://111812577
In some circumstances the missing trait resulted in picking the wrong
branch of some compile time conditionals resulting in code that would
not compile.
rdar://126709253
This PR implements proper support for optional generic associated values
in enum cases. Most of the code changes are supporting generic types in
more contexts in the printer, the rest are making sure we handle the
null pointer case when we try to get the declaration from the type that
represents a generic parameter.
rdar://131112273
The generated header would not compile without these dependencies. Moreover
users probably expect all-public option to be the most permissive filter
including the maximal amount of declarations.
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
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.
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
This allows easier use and more wider API exposure from the Swift stdlib
In the future, all functions and method should incorporate argument labels, but it's not yet clear how
