A property imported from Objective-C, or marked in Swift with the `dynamic` keyword, doesn't have a vtable slot, so can't be identified that way. Use the ObjC selector as the unique identifier to ascribe equality to such components. Fixes rdar://problem/31768669. (While we're here, throw some more execution tests and a changelog note in.)
Adds in Linux platform support for our pthread TLS. Replace usage of
PTHREAD_KEYS_MAX with a sentinel value, as it's tricky to define
cross-platform and was only lightly used inside sanity checks.
Introduce shims for using UBreakIterators from ICU. Also introduce
shims for using thread local storage via pthreads.
We will be relying on ICU and UBreakIterators for grapheme
breaking. But, UBreakIterators are very expensive to create,
especially for the way we do grapheme breaking, which is relatively
stateless. Thus, we will stash one or more into thread local storage
and reset it as needed.
Note: Currently, pthread_key_t is hard coded for a single platform
(Darwin), but I have a static_assert alongside directions on how to
adapt it to any future platforms who differ in key type.
* [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
HeapObject contains an InlineRefCounts. The Swift shim definition of
InlineRefCounts used uint64_t, which has the correct size but the incorrect
alignment on armv7k. This caused the Swift stdlib and the Swift runtime
to disagree about object layouts.
rdar://31664545
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.
Some cases of using isSuperset can cause crashes, this was caused by improper subclassing callouts; this pr resolves those failures (and provides unit tests for that case)
The cases where the bridge was traversed too much now only causes a single bridge out call (without needing to reallocate or thrash retain/release)
String.components(separatedBy: CharacterSet) should be considerably faster now not only for more apporpriate bridging calls but also no longer needing to bridge arrays back and forth.
Resolves the following issues:
rdar://problem/17281998
rdar://problem/26611771
rdar://problem/29738989
This avoids indirection by making calls directly to the C implementations which prevents potentials of mismatched intent or changes of calling convention of @_silgen. The added benefit is that all of the shims in this case are no longer visible symbols (anyone using them was not authorized out side of the Foundation overlay). Also the callout methods in the headers now all share similar naming shcemes for easier refactoring and searching in the style of __NS<class><action> style. The previous compiled C/Objective-C source files were built with MRR the new headers MUST be ARC by Swift import rules.
The one caveat is that certain functions MUST avoid the bridge case (since they are part of the bridging code-paths and that would incur a recursive potential) which have the types erased up to NSObject * via the macro NS_NON_BRIDGED.
The remaining @_silgen declarations are either swift functions exposed externally to the rest of Swift’s runtime or are included in NSNumber.gyb which the Foundation team has other plans for removing those @_silgen functions at a later date and Data.swift has one external function left with @_silgen which is blocked by a bug in the compiler which seems to improperly import that particular method as an inline c function.
By returning `nil` instead of an empty dictionary in the common case where
no exception is encountered, we skip any dictionary-bridging work which
can become expensive if making assertions in a tight loop.
* Mark libc math shims with always_inline attribute
We want these to always be inlined, so mark them with ... always_inline.
The compiler happened to do the right thing with them previously, but we
shouldn't depend on that.
<rdar://problem/30043258> master-next: IRGen/builtin_math.swift failing because sqrt(4) is not constant folded
* Go back to using static inline implementations of sqrt and remainder now that SR-2089 is resolved.
* Fix typo: sqrt -> squareRoot.
* Added test for constant-folding sqrt with -O.
* Added test case requested by jrose.
