This makes sure that whenever we emit `#if defined(__OBJC__)`, the matching `#endif` has a comment `// defined(__OBJC__)`.
This makes both testing and reading the header file easier.
There was a hard to see misalignment between types accepted as
representable in C languages defined in `BuiltinMappedTypes.def` and
those with an associated C type name defined in `PrimitiveTypeMapping`.
While `BuiltinMappedTypes` looked through typealiases,
`PrimitiveTypeMapping` didn't and instead referred only to types by
their identifier. So even when both files defined the same types by
name, their underlying type were only partially handled. An affected
type was `Unicode.Scalar` which is the underlying type of `CWideChar`
and `CChar32`. `Unicode.Scalar` was accepted as a C representable type
but was not printed using a corresponding C type name, breaking the
generated compatibility header.
Another issue with the use of identifiers in the PrimitiveTypeMapping
logic was a limited support for nested types. It would track
`Unicode.Scalar` only as `Scalar`.
This change updates `PrimitiveTypeMapping` to keep track of TypeDecls
instead of identifiers and look through typealiases. This fixes the
issue with `Unicode.Scalar`, allowing it to be printed using the type
defined by an alias and avoid matching an unrelated Scalar. It should
also prevent future types behind typealiases to trigger this same kind
of misalignment.
rdar://157332446
Fix crash when printing references to Unicode.Scalar in the
compatibility header.
Unicode.Scalar should not be printed in the first place, it's a Swift
struct. It should either be considered non-representable or printed as a
C / Objective-C type if that's the intent.
rdar://157120538
For some reason, the new version of clang started to emit -Wc++-keyword
warnings in C mode when -Weverything is enabled. This PR suppresses this
warning.
rdar://155324207
Accept `@cdecl` enums without an explicit C name. The C name defaults to
the Swift one. It is printed using the `SWIFT_ENUM` macro instead of
`SWIFT_ENUM_NAMED`.
Begin accepting the attribute in the form of `@cdecl(cName)`, using an
identifier instead of a string.
For ease of landing this change we still accept the string form. We
should stop accepting it before making this feature available in
production.
There are two main scenarios when printing a compatibility header that
references a @cdecl enum defined in Swift code. (1) When defined in the
same module as it's used we can print the definition normally and then
reference it. (2) When used in a different mode we need to print a
forward declaration before we can reference it.
This change adds printing the forward declaration and fix an issue where
the compiler would instead print an @include of the Swift module. The
import of the Swift module would work only in a local scenario where a
compatibility header and module would be generated under the same name.
However for a distributed frameworks we do not distribute the
compatibility header so this strategy doesn't work. Relying on a forward
declaration should be more reliable in all cases but clients may need to
import the other compatibility header explicitly.
Print @cdecl enums in the C section of the compatibility header. Use and
extend the macros to support C compiler clients.
The macro is adapted to the features supported by the client compiler.
It uses an Objective-C style macro with raw type when available and
fallbacks to a simple typedef for C compatibility.
Start printing `#include` for headers referenced from `@cdecl` function
signatures. This adds on top of the existing tiered imports. We already
print each module referenced from decls printed in the compatibility
header. Previously we printed mostly `@import` with an option to
fallback on a `#import`. This change adds a third fallback to `#include`
when the module is referenced from a `@cdecl` function signature. The
bridging header can also be imported in a similar way.
Add a block for C clients in the compatibility header. This block
contains only the `@cdecl` functions that are printed using only C
types.
This C block is printed above the Objective-C and C++ blocks as if we
add support for `@cdecl` types other languages should be able to
reference them in function signatures. Other languages block don't
duplicate printing the `@cdecl` functions either as they are already
accessible to them.
Compare the names of all extension members first, before attempting weirder and more expensive comparisons like stringified type and mangled name. This gives us a sort order that’s a little more comprehensible to humans.
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.
A couple of the rules that `ModuleContentsWriter::write()` uses to sort declarations didn’t actually work because of an incorrect predicate. In addition, there were a number of situations that could come up in C++ interop (where overloading is permitted) where extensions could not be sorted. Rework extension sorting to look for more kinds of differences between extension members.
Eliminates extraneous newlines between top-level Objective-C declarations in `-emit-objc-header` headers. Specifically, there should now always be exactly one—no more, no less—empty line between `@end` and whatever follows it.
Besides being more aesthetically pleasing, this eliminates ordering-dependent behavior where PrintAsClang would print an extra newline when visiting an empty extension, which meant that the order in which empty and non-empty extensions were visited during printing could result in whitespace differences in the compiler output. Printing the blank line is now conditional on whether `tell()` indicates that characters were actually written to the output.
Fixes rdar://143533893.
The `%check-in-clang-cxx` seems to pass `-fmodule-cache-path` that is
unused in some setups, but not in `%check-in-clang`. Turn the error back
into a warning to avoid the test failing.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
