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
Due to an oversight it seems that we never added a
withContigousStorageIfAvailable implementation to SubString.UTF8View,
which meant that if you sliced a String you lost the ability to get fast
access to the backing storage. There's no good reason for this
functionality to be missing, so this patch adds it in by delegating to
the Slice implementation.
Resolves SR-11999.
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).
In particular, if value is `Any` in a generic context, then `type(of: value)` is
`Any.Protocol` which is never considered optional. As a result, the first
clause here was never actually being used for `print()` or other similar paths.
(Curiously, it _was_ used for string interpolation.)
This changes how we test for an optional type so that the first clause is consistently used for all optionals, even when they are wrapped in `Any` containers.
Fortunately? `print()` was producing the right results for
optionals because of a dynamic cast bug that failed to
unwrap optionals in these same contexts. <sigh>
The original version scanned the entire input string for whitespace and
non-ASCII characters. Both are unnecessary: the C routines we're building on
already stop at non-ASCII characters or non-leading whitespace. So we need only
check the first character for whitespace and verify that all characters are
consumed.
This both improves performance and reduces the amount of code that gets inlined into consumers.
* [stdlib] Slice: customize withContiguous[Mutable]StorageIfAvailable
We can easily make an UnsafeBufferPointer that slices another UnsafeBufferPointer, so let’s allow Slice to vend a slice of the base collection’s contiguous storage, if it provides access to one.
We need to do some index distance calculations to implement this, but those will be constant-time in the usual case where the base collection is a RAC.
https://bugs.swift.org/browse/SR-11957
rdar://58090587
* [test] UnsafeBufferPointer: fix some warnings
* [stdlib] Slice: don’t calculate index distances unless the base provides contiguous mutable storage
This makes Array.first much small and more efficient.
Without this, Array.first compiled down to RandomAccessCollection.first, which ended up in pretty unefficient code.
rdar://problem/46291397
Use _CocoaArrayWrapper.endIndex which returns the NSArray.count.
In the old version, "count" translated to RandomAccessCollection.count, which ended up in multiple calls to endIndex.
The return type of getNumRuntimeFunctionCounters is defined as uint64_t in RuntimeInvocationsTracking.cpp, but it has return type Int in RuntimeFunctionCounters.swift.
Found when compiling the stdlib for WebAssembly, as WebAssembly validates return types. uint64_t corresponds to i64, but Int is i32, so the program fails validation.
The swift_floatNToString, swift_int64ToString, and swift_uint64ToString functions all return a uint64_t from c++. This is a historical accident, but these are SWIFT_RUNTIME_STDLIB_API, which means that we can't trivially change the return type. The result should naturally be size_t or int (it's always small enough to fit into *any* c integer type). However, we can elide the check in the caller at the point that the result is converted to Int, because we know that the check will always pass. This makes it so that the only overhead the wrong type introduces on 32b platforms is zeroing a register, which is free or nearly-free.
The return type of these functions are uint64_t in Stubs.cpp but UInt in the Swift code; this changes the Swift code to match the C++ return type.
Found when compiling the stdlib for WebAssembly, which requires that all return types match: UInt maps to i32 while uint64_t maps to i64, so functions calling these functions fail the validation.
This breaks source compatibility a little bit more than we'd like, so
reverting it for now.
Fixes <rdar://problem/57213598>.
This reverts commit 04fbcc0149.
Previously we did this as a last resort if inference fails. The new
behavior is technically source-breaking, but I suspect nobody
relied on the old behavior.
This can help avoid cycles by eliminating some unnecessary validation work.
Fixes <https://bugs.swift.org/browse/SR-11407>, <rdar://problem/54979757>.
The `_Differentiation` module is the experimental support library for
differentiable programming. It is built when the build-script flag
`--enable-experimental-differentiable-programming` is enabled.
The `Differentiable` protocol generalizes all types that work with
differentiation. It is a core piece of the differentiable programming
project. Other parts depending on the `Differentiable` protocol will
be upstreamed piece by piece.
The `Differentiable` protocol is compiler-known and will be used during
type-checking, SILGen, and the SIL differentiation transform.
These include the pointer-to-pointer and pointer-to-buffer-pointer
initialiser parameters amongst a couple of others, such as
`Unmanaged.fromOpaque`, and the source for the `move[...]` family of
methods.
