The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
BlocksRuntimeStubs is built for the target SDK(s), but it was using one
of the stdlib CMake helpers without setting up the same environment as
the stdlib/ folder is setting.
To avoid problems, like BlocksRuntimeStubs being built with the host
compiler, instead of the just built compiler, and other difficult to
understand problems, create a folder for it in stdlib/private/. This
will allow the usage of the stdlib CMake function in the same environment
that is normally used.
Due to the horrible attrocities against software of the attempt to perform
cross-compilation in the swift build system, we need to emulate the linking
behaviour for Windows with the link against the import library. The emulation
requires the custom creation of import library targets. In order to actually
get the linking semantics correct, the dependendency targets must be created
prior to use (unlike standard CMake). The reordering ensures that we get
correct linkage when building for Windows.
Perform a simple optimization to avoid a number of string comparisions for the
host system.
This is in preparation to make the code here more target agnostic for
porting to the Windows threading primitives. This is used pretty
extensively in the tests, so disabling tests would lose a chunk of
coverage.
Create a new RuntimeUnittest library alongside the other stdlib unit
tests so we can write C++ runtime unit tests callable from lit.
Move runtime exclusivity tests into the stdlib unittest library and
create lit tests so we can verify that the runtime crashes with an
error message.
On Linux it used to be possible to build only the stdlib, without the
SDK overlays, like so:
```
utils/build-script -- --build-swift-stdlib --build-swift-sdk-overlay=0
```
However this invocation now results in the following error:
```
+ /usr/bin/cmake --build /home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swift-linux-x86_64 -- -j8 all swift-stdlib-linux-x86_64
ninja: error: '/home/modocache/GitHub/apple/swift/stdlib/private/SwiftPrivatePthreadExtras/swiftGlibc-linux-x86_64', needed by 'stdlib/private/SwiftPrivatePthreadExtras/linux/x86_64/SwiftPrivatePthreadExtras.o', missing and no known rule to make it
utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
```
The problem is that SwiftPrivatePthreadExtras is always built, regardless
of whether the SDK overlay is built. I believe there's an explicit check
against this for Darwin platforms to prevent the same error.
The solution, implemented here, is to add the same check for Linux.
This is a small helper library to communicate information back to
swift-reflection-test from a test swift executable. Each swift test
file under test/Reflection should link this library to get the main
test hook to send responses back to the test tool.
SwiftPrivateDarwinExtras is used by non-Darwin platforms as well; its
name is misleading. Rename it to SwiftPrivateLibcExtras, which is
closer to its actual function.
This brings down StdlibUnittest build time to 90 seconds with either
a DebugAssert or a ReleaseAssert compiler.
The new library, StdlibCollectionTests, is only built when running
validation tests.
These APIs will be used for writing automation tools in Swift. Just
like other private APIs, this module is not exposed to extrenal users.
The primary motivation for doing instead of using NSCoder this is that
NSCoder does not work with structs and Swift containers. Using classes
for everything just to satisfy NSCoder forces unnatural code.
This API requires two times (!) less boilerplate than NSCoding, since
the same method is used for serialization and deserialization. This API
is also more type-safe, it does not require the user to write 'as' type
casts, unlike NSCoding.
Please take a look at
validation-test/stdlib/SwiftPrivateSerialization.swift to see the
intended use pattern.
The performance of the underlying implementation is already decent, and
there's a lot of room for improvement.
This is a re-commit of r25678, with a fix for 32-bit platforms.
Swift SVN r25877
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
