Don't complain if the empty array buffer singleton is set to mutable.
This can happen if reserveCapacity is called with a 0-capacity for an empty array.
In this case the resulting array is still the empty array singleton.
For the compiler, it's safe to treat the empty array singleton as "mutable", because there is never anything written to an array with zero capacity:
all mutating array operations do any form of capacity/size > 0 check in addition to the uniqueness check.
Unfortunately the empty array singleton sometimes needs such special handling with is not obvious (not to say hacky).
This wrong check only fired in very specific optimization scenarios, where the inliner and the COW optimizations must play together in a certain way.
I could not find an isolated test case for this problem.
rdar://problem/71107908
Instead of doing the sanity checks by default (with an assert-build of the stdlib), only do the checks if the environment variable SWIFT_DEBUG_ENABLE_COW_SANITY_CHECKS is set to true.
The checks can give false alarms in case a binary is built against a no-assert stdlib but run with an assert-stdlib.
Therefore only do the checks if it's explicitly enabled at runtime.
rdar://problem/65475776
Use the new builtins for COW representation in Array, ContiguousArray and ArraySlice.
The basic idea is to strictly separate code which mutates an array buffer from code which reads from an array.
The concept is explained in more detail in docs/SIL.rst, section "Copy-on-Write Representation".
The main change is to use beginCOWMutation() instead of isUniquelyReferenced() and insert endCOWMutation() at the end of all mutating functions. Also, reading from the array buffer must be done differently, depending on if the buffer is in a mutable or immutable state.
All the required invariants are enforced by runtime checks - but only in an assert-build of the library: a bit in the buffer object side-table indicates if the buffer is mutable or not.
Along with the library changes, also two optimizations needed to be updated: COWArrayOpt and ObjectOutliner.
This has two advantages:
1. It does not force the Array in memory (to pass it as inout self to the non-inlinable _createNewBuffer).
2. The new _consumeAndCreateNew is annotated to consume self. This helps to reduce unnecessary retains/releases.
The change applies for Array and ContiguousArray.
malloc introspection is a platform feature that is unavailable on
OpenBSD. There is no workaround for the feature, so we have to assume
that allocations succeed in allocating exactly the amount of memory
requested, and nothing more.
Here a new mallocSize shim is introduced so the feature check for malloc
introspection is pushed to the shims, rather than using os checks
directly from Swift. Not every use of malloc_size has been converted
yet; ManagedBuffer.swift still remains. However, this module requires
special care to fix, which will be done separately.
A previous commit [1] identified and fixed a benign race on
`_swiftEmptyArrayStorage`. Unfortunately, we have some code duplication
and the fix was not applied to all the necessary places. Essentially,
we need to ensure that the "empty array storage" object that backs many
"array like types" is never written to.
I tried to improve the test to capture this, however, it is very
finicky. Currently, it does not go red on my system even when I remove
the check to avoid the benign race in Release mode.
Relevant classes: Array, ArraySlice, ContiguousArray, ArrayBuffer,
ContiguousArrayBuffer, SliceBuffer.
[1] b9b4c789f3
rdar://55161564
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
This fixes a major perform bug involving array initialization from any
contiguously stored collection. This is not a recent regression. This fix
results in a 10,000X speedup (that's 4 zeros) for this code path:
func initializeFromSlice(_ a: [Int]) -> [Int] {
return Array<Int>(a[...])
}
A benchmark is included.
Inlinable code is permitted to rely on these associated types, so we
need to make sure their declarations are printed in the parseable
interface.
Part of rdar://problem/43824052
- __SwiftNativeNSArrayWithContiguousStorage.withUnsafeBufferOfObjects
- __ContiguousArrayStorageBase._getNonVerbatimBridgingBuffer()
- __ContiguousArrayStorageBase._getNonVerbatimBridgedCount()
- Most __SwiftDeferredNSArray members
- HeapBuffer was at the wrong abstraction level, for no good reason. We have ManagedBuffer for the general case; we don’t need a slightly less general variant of it.
- Current usages of HeapBuffer are hyper specific: they all are flat buffers of AnyObjects, facilitating bridging. It makes sense to dedicate _HeapBuffer for this single usecase.
- Introduce a dedicate ManagedBuffer subclass for bridging buffers. This will make it slightly easier to recognize these in heap dumps.
- Inlinability audit.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
