This just is using the standard formatting suggested by clang-format.
This fixes the issue with forward declarations being injected into the
search order.
Remove the use of the `LLVM.h` forward declarations from the
compatibility shims. This allows us to fully isolate the target side
from the LLVM namespace ensuring that we prevent ODR violations when
LLVM is linked into the same address space.
Remove the flag being specified in multiple locations unnecessarily.
The flags flow downwards to all the subdirectories. Use that to apply
the C/C++ flags from the root of the runtime repository.
This is needed in situations where the minimum deployment target is
specified in build-script -- these libraries do not to obey to that
since we need to ensure we are able to back deploy those correctly.
Addresses rdar://59249988
The runtime that shipped with Swift 5.1 and earlier had a bug that interfered with backward
deployment of binaries that dynamically check for protocol conformances on conditionally-available
tests. This was fixed in the top-of-tree Swift runtime by https://github.com/apple/swift/pull/29887;
however, that doesn't do much good for running binaries on older OSes that don't have that fix.
In order for binaries built with a newer Swift compiler to run successfully on older OSes,
introduce a compatibility hook that replaces the conformance cache implementation in the original
OS runtime with a version based on the current implementation that has the fix for the protocol
conformance bug. Fixes rdar://problem/59460603
Xcode and other build systems currently link the compatibility libraries into every executable
or dynamic library, which can cause a chain of objc_getClass compatibility hacks to pile up if
a program loads a lot of dynamic libraries. In the static constructor that installs the
objc_getClass compatibility shim, check whether it's running on behalf of the main executable
before installing the shim.
When building on macOS without the standard library but building the
extra toolchain content, we would fail to configure due to the missing
include of the `AddSwiftStdlib`.
This is the only dependency it has on libswiftCore. Looking this up at runtime allows its use in programs that don't link libswiftCore but might eventually load and run Swift code, such as xctest.
While we're in there, enable tests in files ending with `.c`.
rdar://problem/55274114
Add code to the 5.0 compatibility library that scans for conformances pointing to a NULL type and rewrites them to point to a dummy type that the 5.0 protocol conformance checking code will safely ignore.
