We want to enable overlays to import their shims as @_implementationOnly, so that the shims disappear from the public interface.
However, this isn’t possible when a shim is called from an @inlinable func, because then the existence (and definition) of the shim needs to be available to all callers of it.
Unfortunately Foundation’s Data has three instances where it calls _SwiftFoundationOverlayShims._withStackOrHeapBuffer within @inlinable code:
- Data.init<S: Sequence>(_: S)
- Data.append<S: Sequence>(contentsOf: S)
- Data.replaceSubrange<C: Collection>(_: Range<Int>, with: C)
Rewrite the first two to write sequence contents directly into the target Data instance (saving a memcpy and possibly a memory allocation).
In replaceSubrange, add fast paths for contiguous collection cases, falling back to a Swift version of _withStackOrHeapBuffer with a 32-byte inline buffer.
The expectation is that this will be an overall speedup in most cases, with the possible exception of replaceSubrange invocations with a large non-contiguous collection.
rdar://58132561
* Mutations of slices of data should preserve relative indexing as well as cow semantics of slices
* Ensure hashes of ranges are uniform to the expected hash for Data
* Correct a few mistakes in the slice mutation tests
* Update sequence initializations to avoid directly calling mutableCopy which prevents slice offset mismatches
* Avoid invalid index slices in creating mirrors
* Restore the original Data description
* Resetting a slice region should expand the slice to the maximum of the region (not a out of bounds index of the backing buffer)
* Remove stray comment and use a stack buffer for sequence appending
* Return false when allocations fail in _resizeConditionalAllocationBuffer (not yet in use)
* Enumeration of regions of a slice should be limited to the slice range in the case of custom backing (e.g. dispatch_data_t)
* adjust assertion warnings for data indexes that are negative
* [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 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.
