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.
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++.
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
When a `@_cdecl` function is printed to a generated header, the types
it uses in its signature are not forward declared or imported, so the
header isn't usable unless you also add another Objective-C declaration
to the module (like a class or protocol) that uses the types to force
it.
