of OSLogMessage constant evaluable and remove @_transparent annotation
from the methods. Also, improve diagnostics in the OSLogOptimization
pass as now it rely on seeing the appendInterpolation/Literal calls.
Ensure that the swift-reflection-test binary is built for Windows by
default. This is preventing tests from executing on Windows. There are
dependencies which were already specified for Linux even, the tool just
was disabled due to an invalid check.
library so that the type: OSLogByteBufferBuilder is no longer needed.
This would make backward deployment of code using the new log APIs
easier, besides other minor benefits.
@_semantics("constant_evaluable") annotation to denote constant
evaluable functions.
Add a test suite that uses the sil-opt pass ConstantEvaluableSubsetChecker.cpp
to check the constant evaluability of function in the OSLog
overlay.
Misaligned indices were fixed in 5.1, but we should disable the test
when testing back deployment.
Adds a shared helper to StdlibUnittest for the run time check.
interpolation of Int types in the new os_log APIs so that it is
easier to extend to other integer types. Based on this, add support
for interpolating Int32 types.
the builtin.globalStringTablePointer to the new OSLog overlay.
Modify the new OSLog implementation to use this SPI instead of
`withCString` to pass the (compiler-generated) format string to
the C os_log_impl ABI.
Move the OSLogOptimization pass before constant propagation in
the pass pipeline so that the SPI and the builtin it uses can be
folded to a string_literal instruction.
Update OSLogTests to work with the changes in the implementation.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
This was already being done for the stderr, but not for stdout. Doing
this means that we no longer get spurious carriage returns on the stdout
output stream on Windows. This is needed for supporting the
validation test suite on Windows.
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
