The new definition diverges from the existing hashValue: it feeds all path components to the hasher, rather than just a limited subset.
Hashing all the bits that are compared in == is necessary to ensure proper operation of the hash table.
* [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
