Explanation: There was a null pointer dereference in reverse interop
when we wanted to expose an ObjC class written in Swift. There was a
crash during generating the scaffolding we do for Clang types. Since
the type is written in Swift, no such scaffolding is needed, this patch
skips this operation avoiding the null dereference.
Scope: Reverse C++ interop when exposing @ObjC classes written in Swift.
Issues: rdar://154252454
Original PRs: #82684
Risk: Low, the fix is narrow to the affected scenario.
Testing: Added a compiler test.
Reviewers: @egorzhdan
If a Swift class has a field, which has a closure type, which takes an instance of a `CF_OPTIONS`/`NS_OPTIONS` type as a parameter, the reverse interop logic would generate an invalid Objective-C++ header for such type.
This was discovered with UIKit's `UIControlState` type, which is declared with `NS_OPTIONS` in Objective-C, then renamed to `UIControl.State` with API Notes, and then re-exported to Objective-C++ via the generated header.
rdar://129622886
(cherry picked from commit e95c9ecffc)
Explanation: Fix a compilation error in the generated reverse interop
header when a nested foreign type is used in a generic context and it is
reexposed to C++.
Issue: rdar://148597079
Risk: Low, the fix is fairly targeted to the affected scenario.
Testing: Added tests to test suite
Reviewer: @egorzhdan
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
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.
This macro applies always_inline in addition to inline. It also applies artificial, which lets debugger know that this is an artificial function. The used attribute is added in debug builds to ensure that the symbol is emitted in the binary so that LLDB can invoke it.
Each emitted declaration is annotated with the external_source_symbol with its own USR, to allow Clang's indexer to recognize this declaration as a Swift declaration with a specific USR
