- Use SWIFT_RUNTIME_EXPORT instead of SWIFT_RT_ENTRY_VISIBILITY for exposed functions
- Use `_swift_` prefixes on the names of exposed functions
- Make the global counters and per-object counters cache thread-safe by using locks
When building the stdlib for Windows x86_64, we would see the following error:
swift/stdlib/public/core/RuntimeFunctionCounters.swift:95:19: error: '(UnsafeRawPointer, Int64) -> Void' is not representable in Objective-C, so it cannot be used with '@convention(c)'
@convention(c) (_ object: UnsafeRawPointer, _ functionId: Int64) -> Void
^
This is caused by `Int64` not being mapped as on Windows x86_64, `CLong`
is mapped to `Int32` and `CLongLong` is mapped to `Int`. This causes
the `Int64` to fail to be reverse-mapped to a C type causing the FFI
construction failure.
Move bits mask from Metadata.h to SwiftShims's HeapObject.h. This
exposes the bit masks to the stdlib, so that the stdlib doesn't have
to have its own magic numbers per-platform. This also enhances
readability for BridgeObject, whose magic numbers are mostly derived
from Swift's ABI.
makeUnique hoisting can create a situation where we hit an assert in
_reserveCapacityAssumingUniqueBuffer that the buffer is not unique if we use
_makeMutableAndUniqueOrPinned to replace
_makeUniqueAndReserveCapacityIfNotUnique.
It is actually fine do to the replacement because we will make the buffer unique
_reserveCapacityAssumingUniqueBuffer if the capacity is zero so adjust the
assert accordingly.
do {
if (someCond) {
// array.append(...)
_makeUniqueAndReserveCapacityIfNotUnique(&array)
_reserveCapacityAssumingUniqueBuffer(&array)
_appendElementAssumeUniqueAndCapacity(&array, …)
} else {
// array[i] = …
_makeMutableAndUniqueOrPinned(&array)
addr = _getElementAddress(&array)
store 1, addr
}
} while();
to:
_makeMutableAndUniqueOrPinned(&array) // does not replace empty arrays.
do {
if (someCond) {
// array.append(...)
_reserveCapacityAssumingUniqueBuffer(&array) // hit the assert.
_appendElementAssumeUniqueAndCapacity(&array, …)
} else {
// array[i] = …
addr = _getElementAddress(&array)
store 1, addr
}
} while();
Tested by the performance test if we build the stdlib with assertions.
rdar://34149935
The various _*Indexable protocols only exist to work around the lack of
recursive protocol constraints. Eliminate all of the *_Indexable protocols,
collapsing their requirements into the corresponding Collection protocol
(e.g., _MutableIndexable —> Collection).
This introduces a number of extraneous requirements into the various
Collection protocols to work around bugs in associated type
inference. Specifically, to work around the lack of "global" inference
of associated type witnesses. These hacks were implicitly present in
the *Indexable protocols; I've made marked them as ABI FIXMEs here so
we can remove them when associated type inference improves.
Fixes rdar://problem/21935030 and a number of ABI FIXMEs in the library.
Rather than using the default slice type when slicing the collection produced
by a lazy map or filter, slice the base collection and form a new
lazy map/filter collection from it. This allows any optimizations provided by
the collection SubSequence type to kick in, as well as ensuring that slicing
a lazy collection provides the same type as producing a lazy collection of a
slice.
This is technically source-breaking, because someone could have spelled out
the types of slicing a lazy filter or map… but it seems unlikely to matter
in practice and the benefits could be significant.
Fixes ABI FIXME’s #28 and #46.
Make the Indices types conform to the appropriate Collection protocol:
* Collection.Indices: Collection
* BidirectionalCollection.Indices: BidirectionalCollection
* RandomAccessCollection.Indices: RandomAccessCollection
Introduce (recursive) constraints that make the *Collection constraint
of SubSequence match that of its enclosing *Collection, e.g.,
MutableCollection.SubSequence conforms to MutableCollection.
Fixes rdar://problem/20715031 and more of SR-3453.
Addressed ABI FIXME’s #4, #5, #104 and #105, making Sequence’s
SubSequence conform to Sequence, with the same element type, and for
which the SubSequence of a SubSequence is the same SubSequence.
Fixes SR-318 / rdar://problem/31418206.
Int is still an insufficient stride type for binary integers,
but this improves the situation for values at the extremes of the
concrete integer types.
