Data.append now calls Data.count’s setter, which used to have a bug in previously shipped versions of the Foundation overlay (#28918).
To prevent working code from breaking when recompiled with the current version, avoid calling Data.count’s setter directly. Instead, extract its implementation (conveniently already packaged into a nested function) into a named method, marking it @_alwaysEmitIntoClient.
Data provides a settable `count` property. Its expected behavior is undocumented, but based on the implementation, it is intended to zero-extend (or truncate) the collection to the specified length.
This does not work correctly if we start with an empty Data and we try to increase the count by a small integer:
```
import Foundation
var d = Data()
d.count = 2
print(d.count) // ⟹ 0 ⁉️
d.count = 100
print(d.count) // ⟹ 100 ✓
```
It looks like this bug was introduced with the Data overhaul that shipped in Swift 5.
(This issue was uncovered by https://github.com/apple/swift/pull/28918.)
rdar://58134026
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
To implement swift_errorBridgingInfo, the Foundation overlay needs to import private runtime headers. Now that we cannot statically link the Foundation overlay, there is no point to keeping this workaround in the overlay any more.
This effectively reverts https://github.com/apple/swift/pull/16677.
rdar://problem/57809306
This makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
* Replace stdlib and test/stdlib 9999 availability.
macOS 9999 -> macOS 10.15
iOS 9999 -> iOS 13
tvOS 9999 -> tvOS 13
watchOS 9999 -> watchOS 6
* Restore the pre-10.15 version of public init?(_: NSRange, in: __shared String)
We need this to allow master to work on 10.14 systems (in particular, to allow PR testing to work correctly without disabling back-deployment tests).
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
* Update Decimal.swift
Fix `Decimal.magnitude` so that `Decimal.nan.magnitude` is no longer incorrectly `0`.
Port changes from apple/swift-corelibs-foundation#1759, crucially correcting an error where `(0 as Decimal).doubleValue` returned `.nan`.
* [gardening] Zap indentation error
* Add test for `Decimal.nan.magnitude`
* Apply reviewer suggestion
Clean up `doubleValue`
