When we're building static libraries, we don't need to include the
threading objects in both Concurrency and Core, and we also don't need
two copies of the threading library's fatal error handler.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
Swift 5.7 added stronger index validation for `String`, so some illegal cases that previously triggered inconsistently diagnosed out of bounds accesses now result in reliable runtime errors. Similarly, attempts at applying an index originally vended by a UTF-8 string on a UTF-16 string now result in a reliable runtime error.
As is usually the case, new traps to the stdlib exposes code that contains previously undiagnosed / unreliably diagnosed coding issues.
Allow invalid code in binaries built with earlier versions of the stdlib to continue running with the 5.7 library by disabling some of the new traps based on the version of Swift the binary was built with.
In the case of an index encoding mismatch, allow transcoding of string storage regardless of the direction of the mismatch. (Previously we only allowed transcoding a UTF-8 string to UTF-16.)
rdar://93379333
This reintroduces an intentionally misspelled word in a doc comment for the `Unicode.Scalar.Properties.nameAlias` property. This "typo" was accidentally "fixed" in be13b470aa.
As discussed on the forum, `BidirectionalCollection` requirements as
currently stated can be interpreted to forbid conforming types from
accepting indices that lie between valid (i.e., reachable) indices
in the collection. Among other undesirable effects, this
interpretation would render SE-0180 (String.Index overhaul)
incompatible with these requirements.
Update the wording to clarify that the requirements only apply to
valid indices. (Collection protocols do not constrain the behavior of
invalid indices — it’s up to individual collection types to implement
them as they wish.)
https://forums.swift.org/t/string-index-unification-vs-bidirectionalcollection-requirements/55946
rdar://92297280
The Windows ARM64 build with the toolchain fixes exposed the missed type
aliasing for `CLong` when building Foundation. With this it is finally
possible to build a complete SDK for Windows AArch64.