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 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.
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.
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.
Revert #20194, which seems to be more trouble than it's worth. Instead, move the functions that SwiftPrivate needs back into LibcShims.h/cpp as SPI.
rdar://problem/45817565
The changes in https://github.com/apple/swift/pull/19614 require Darwin/Glibc to build first. This usually happened anyway (and thus the problem wasn't noticed for a while) but sometimes SwiftPrivate would win the race and the build would fail.
rdar://problem/45624328
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
SwiftPrivate/PRNG.swift:
- currently uses `theGlobalMT19937`;
- previously used `arc4random` (see #1939);
- is obsoleted by SE-0202: Random Unification.
* Remove case destructuring to _
* Remove some Iterator.Element
* Which idiot wrote this? Oh.
* Switch NibbleSort to just use default impls... shouldn't change perf
Streamline internal String creation. Previously, everything funneled
into a single generic function, however, every single call of the
generic funnel had relevant specific information that could be used
for a more efficient algorithm.
In preparation for efficiently forming small strings, refactor this
logic into a handful of more specialized subroutines to preserve more
specific information from the callers.
