Introduces a _ThreadLocalStorage struct to hold thread-local, but
global resources. Set it up to host a UBreakIterator and a cache key
for resetting text.
UBreakIterators are extremely expensive to create on the fly, so we
store one for each thread. UBreakIterators are also expensive to bind
to new text, so we cache the text it's currently bound to in order to
help avoid it.
The struct can be expanded with more functionality in the future, but
the standard library should only ever use a single key, and thus
everything should go on this struct. The _ThreadLocalStorage struct is
not meant to be copyable, creatable (by anyone else except the
once-per-thread initialize routine), and should accessed through the
pointers it provides.
Future immediate directions could include cashing multiple
UBreakIterators (e.g. avoid a text reset for mutual character
iteration patterns, etc).
Test added in test/stdlib/ThreadLocalStorage.swift.
The following code behaves incorrectly due to the presence of this
overload.
let a: Int = 1
let b: Int? = 2
let c: Int? = nil
let result: [Any] = [a, b, c].flatMap { $0 }
Fixes: <rdar://problem/31910642>
* [Foundation] Refactor the backing of IndexPath to favor stack allocations
The previous implementation of IndexPath would cause a malloc of the underlying array buffer upon bridging from ObjectiveC. This impacts graphical APIs (such as UICollectionView or AppKit equivalents) when calling delegation patterns. Since IndexPath itself can be a tagged pointer and most often just a pair of elements it can be represented as an enum of common cases. Those common cases of empty, single, or pair can be represented respectively as no associated value, a single Int, and a tuple of Ints. These cases will be exclusively stack allocations, which is markably faster than the allocating code-path. IndexPaths that have a count greater than 2 will still fall into the array storage case. As an added performance benefit, accessing count and subscripting is now faster by aproximately 30% due to more tightly coupled inlining potential under whole module optimizations. Accessing count is also faster since it has better cache-line effeciency (lesson learned: the branch predictor is more optimized than pointer indirection chasing).
Benchmarks performed on x86_64, arm and arm64 still pending results but should be applicable across the board.
Resolves the following issues:
https://bugs.swift.org/browse/SR-3655https://bugs.swift.org/browse/SR-2769
Resolves the following radars:
rdar://problem/28207534
rdar://problem/28209456
* [Foundation] remove temp IndexPath hashing that required bridging to ref types
* [Foundation] IndexPath does not guarentee hashing to be the same as objc
This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
I had optimistically written the code here optimistically hoping #7837 would land in time for me to merge, but that didn't happen, so adjust some things to match the current 12-byte object header size on 32-bit, and introduce some ABI constants for the expected 32- and 64-bit object header sizes we can assert against so that we have some robustness when it eventually changes again. Implements rdar://problem/31768303.
With more recent versions of LLVM (e.g., used with master-next) the
argument of REQUIRES is parsed as an expression. Do not use "rdar"
URLS for these since it confuses lit.
Now that `String` conforms to the `BidirectionalCollection` protocol, in
the expression `let x = [""].joined()` the best matching overload for
`joined` is no longer the one returning `String`.
Fixes: <rdar://problem/31899440>
This eliminates the counting step for a lazy filtered collection
when converting it into an array by treating the collection
as a sequence when copying elements. FlattenCollections already
have this behavior. (SR-4164)
* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
With the old remangler this test crashed at runtime when trying to create the mangled name for a class with a non-ascii module name.
rdar://problem/31875699
Many of StringCore private APIs, when the StringCore is itself a
substring, expect relative offsets rather than absolute offsets. This
fixes a bug in the sub-0x300 fast path where we were using absolute
offsets. Test cases added.
