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.
When force linking auto-linked libraries, an overlay will fail to link if the dependence
libraries are missing from the source. This change provides linker flags
to search overlay libraries from the SDK.
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
Remove the gratuitous use of the GNU extensions to implement the OS logging
module. This allows us to enable `-Werror=gnu` globally, even on macOS builds.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
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.
Static builds of the standard library and the SDK overlay are
unsupported post ABI stability. Disallow building of the standard
library and SDK overlay statically for Darwin platforms.
* 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.
