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.
We're using C++ 14+ at least now across the project so these should not be necessary. It's also kind of wild that the definitions we had across different subsystems had different definitions.
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
We do not support any sort of indirect enums yet, the code gets into an
infinite recursion. Let's skip exporting these types to C++ for now
until proper support is implemented.
rdar://134852756
Previously the code got the declaration for types with generic
arguments and the printer used the declaration. This was a lossy
operation, we printed the type with generic parameters instead of the
arguments. This patch makes sure we print the type with the arguments.
Unfortunately, the code structure is not the most clear, type printing
is currently inherently part of the function signature printing. This
code path needs to be factored out in the future to make the code easier
to understand.
rdar://130679337
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.
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
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.
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
This allows you to import a method that returns the type of the context in which the method is declared when such
type is a generic parameter in another type. This means that it's now possible to bridge the initializer for
RawRepresentable enums.
