This isn't a "complete" port of the standard library for embedded Swift, but
something that should serve as a starting point for further iterations on the
stdlib.
- General CMake logic for building a library as ".swiftmodule only" (ONLY_SWIFTMODULE).
- CMake logic in stdlib/public/core/CMakeLists.txt to start building the embedded stdlib for a handful of hardcoded target triples.
- Lots of annotations throughout the standard library to make types, functions, protocols unavailable in embedded Swift (@_unavailableInEmbedded).
- Mainly this is about stdlib functionality that relies on existentials, type erasure, metatypes, reflection, string interpolations.
- We rely on function body removal of unavailable functions to eliminate the actual problematic SIL code (existentials).
- Many .swift files are not included in the compilation of embedded stdlib at all, to simplify the scope of the annotations.
- EmbeddedStubs.swift is used to stub out (as unavailable and fatalError'd) the missing functionality.
This let the optimizer generate efficient code for generic array loops (note that generic functions are not inlined by default).
Note that the same change is not done for `Array` because this might increase code size due to Array's bridging code.
rdar://108746069
Types that have "value semantics" should not have lexical lifetimes.
Value types are not expected to have custom deinits. Are not expected to
expose unsafe interior pointers. And cannot have weak references because
they are structs. Therefore, deinitialization barriers are irrelevant.
rdar://107076869
Cleanup code in _modify accessors will only run reliably if it is put in a defer statement.
(Statements that follow the `yield` aren’t executed if the yielded-to code throws an error.)
* [stdlib] Deprecate MutableCollection._withUnsafeMutableBufferPointerIfSupported
In Swift 5.0, [SE-0237] introduced the public `MutableCollection.withContiguousMutableStorageIfAvailable` method. It’s time we migrated off the old, underscored variant and deprecated it.
The default `MutableCollection.sort` and `.partition(by:)` implementations are currently calling this hidden method rather than the documented interface, preventing custom Collection implementations from achieving good performance, even if they have contiguous storage.
[SE-0237]: https://github.com/apple/swift-evolution/blob/master/proposals/0237-contiguous-collection.md
* [test] Update tests for stdlib behavior changes
* Update stdlib/private/StdlibCollectionUnittest/CheckMutableCollectionType.swift
Co-authored-by: Nate Cook <natecook@apple.com>
* Update stdlib/private/StdlibCollectionUnittest/CheckMutableCollectionType.swift
Co-authored-by: Nate Cook <natecook@apple.com>
* Apply suggestions from code review
Co-authored-by: Nate Cook <natecook@apple.com>
* [test] LoggingMutableCollection: Fix logging targets
* [stdlib] Fix warning by restoring original workaround
Co-authored-by: Nate Cook <natecook@apple.com>
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
to check for improperly nested '@_semantic' functions.
Add a missing @_semantics("array.init") in ArraySlice found by the
diagnostic.
Distinguish between array.init and array.init.empty.
Categorize the types of semantic functions by how they affect the
inliner and pass pipeline, and centralize this logic in
PerformanceInlinerUtils. The ultimate goal is to prevent inlining of
"Fundamental" @_semantics calls and @_effects calls until the late
pipeline where we can safely discard semantics. However, that requires
significant pipeline changes.
In the meantime, this change prevents the situation from getting worse
and makes the intention clear. However, it has no significant effect
on the pass pipeline and inliner.
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.
Confirmed this change on using the swift-5.2-DEVELOPMENT-SNAPSHOT-2020-01-22-a
toolchain, Apple Swift version 5.2-dev (Swift d3f0448a4c).
Fixes rdar://problem/58717942
All mutating Array functions must be annotated with semantics, because otherwise some high level optimizations get confused.
The semantic attributes prevent inlining those functions in high-level-sil.
This is need so that the optimizer sees that the Array is taken as inout and can reason that it's modified.
This restriction is not needed anymore when we’ll have COW representation in SIL.
rdar://problem/58478089
Just copy the buffer if it's not unique.
This also implies that if there is a copy-on-write in remove, "shrink" the capacity of the new buffer to the required amount of elements (instead of copying the capacity of the original buffer).
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
[stdlib] Make unsafe array initializer public
This implements SE-0245. The public versions of this initializer call
into the existing, underscored version, which avoids the need for
availability constraints.
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.
