The pthread dependency has been lifted through the Windows port
generalising the SwiftThreadExtras. Enable building these unit test
binaries which are needed for the validation test suite.
The comment in the function said:
// This function is implemented in Objective-C because Swift does not support
// failing initializers.
which hasn't been true since swift 1.1.
StdlibUnittest uses an AtomicBool to track whether a failure has ocurred
in a test. Before this, expectFailure could have a false-positive
failure due to a race condition on the _anyExpectFailed.
The following interleaving would trigger the issue:
A: loads false
A: stores false
B: loads false
A: stores true
B: stores false
A: loads false (after body)
This causes A to see a false-positive failure.
While we're in there, make SwiftReflectionTest's debugLog function take an @autoclosure so we don't waste a ton of time constructing log messages that are never logged.
In the Android paths of the spawnChild function, the parent was creating
a pipe that was never closed, which led to FD starvation. In some tests
with a lots of expected crashes, the childs will not spawn anymore since
the linker would not have enough descriptors to open the shared
libraries, while in other tests which closed the child descriptors as
part of the last test, the parent process will hang waiting those
descriptors to be closed, which will never had happened.
The solution is implement the missing parts of the code, which tried to
read from the pipe in the parent side (using select and read, taking
pieces from other parts of the code). This should match the fork/execv
path used by Android and Haiku to the spawn code used by the rest of the
platforms.
This change fixes StdlibUnittest/Stdin.swift,
stdlib/InputStream.swift.gyb,
stdlib/Collection/FlattenCollection.swift.gyb and
stdlib/Collection/LazyFilterCollection.swift.gyb, which were the last 4
tests failing in Android AArch64.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
Since the `_FDOutputStream` type does not conform to a protocol, the
required interface was missed. The changes in
fbce6e7873 introduced a use of the
`isClosed` property which broke the Windows build. This should fix the
windows build.
When testing runtime lookup changes, we want to make sure each test runs in isolation. Add a new modifier, `.requireOwnProcess()`, to enable tests to guarantee they’re run in isolation.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
Windows uses carriage returns and newlines. The string matching is
sensitive to this. Simply erase carriage returns from the standard
error stream to compensate.
Use `ThreadHandle(bitPattern:)` rather than `unsafeBitCast` for the
conversion of the `uintptr_t` to the `HANDLE`. Convert a variable from
`var` to `let` binding.
The recent changes to the UnsafemutablePointer prevented the "abuse" of
the type for casting. Switch to `unsafeBitCast`. This should repair
the Windows build.
The “string length” primitive was validating the string data as valid UTF-8
to get the length. However, mangled names, which get read by this operation,
are not always valid UTF-8. Just count the bytes until a ‘0’ and don’t
validate.
Add a vectored exception handler for illegal instructions on Windows.
This allows us to emulate `signal(SIGTRAP, ...)`. This allows better
coverage of tests.
Adjust the abort behaviour on Windows. The aborts would cause a large
number of dialogs to appear. This reduces the load a bit and is crucial
for getting tests to run without manual intervention.
Windows uses DOS line endings which appear through the PIPE endpoints.
We currently split on line feeds only, leaving the carriage return in
place. Without this, the messages on the communication pipe would not
be interpreted correctly.
Turns out some people used this type despite it being prefixed with
`_stdlib_`, so we have to keep it, with an obsoletion message this time.
Second copy of the same type is kept available past Swift 5 in
SwiftPrivate for use in tests.
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.
