The _StringProcessing module provides a generic, collection-based
`contains` method that performs poorly for ranges and closed ranges.
This addresses the primary issue by providing concrete overloads
for Range and ClosedRange which match the expected performance for
these operations.
This change also fixes an issue with the existing range overlap tests.
The generated `(Closed)Range.overlap` tests are ignoring the "other"
range type when generating ranges for testing, so all overlap tests
are only being run against ranges of the same type. This fixes things
so that heterogeneous testing is included.
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.
After moving to the new llvm pass pipeline this function no longer gets
inlined. Leading to 150% regressions in ObjectiveCBridge benchmarks.
rdar://98533158
Currently, a simple function such as:
```swift
func makeSingleElementRange(n: Int) -> Range<Int> {
return Range(n...n)
}
```
will result in the following assembly under optimisation:
```
output.makeSingleElementRange(n: Swift.Int) -> Swift.Range<Swift.Int>:
sub rsp, 40
mov qword ptr [rsp + 8], rdi
mov qword ptr [rsp + 16], rdi
call (lazy protocol witness table accessor for type Swift.Int and conformance Swift.Int : Swift.SignedInteger in Swift)
mov rcx, rax
mov rsi, qword ptr [rip + ($sSiN)@GOTPCREL]
mov rdx, qword ptr [rip + ($sSiSxsWP)@GOTPCREL]
lea rax, [rsp + 24]
lea rdi, [rsp + 8]
call ($sSnsSxRzSZ6StrideRpzrlEySnyxGSNyxGcfC)@PLT
mov rax, qword ptr [rsp + 24]
mov rdx, qword ptr [rsp + 32]
add rsp, 40
ret
```
Mark the `init` as inlinable so these functions can be properly optimised.
Also add a missing line of documentation.
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.
When the stdlib says not to check, it’s a good idea to actually not have any checking, so that we leave existing code paths unchanged. (And because we do trust that the stdlib is responsible about such things.)
Unchecked APIs must still perform checks in debug builds to ensure that invariants aren’t violated.
(I.e., these aren’t a license to perform invalid operations — they just let us get rid of the checks when we know for sure they are unnecessary.)
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
The previous documentation of this operator in `Range` context was lost sometime during 2017. This new version is a simplified version of the original copy, with substantial inspiration taken from the present-day documentation of the same operator on `Optional`.
Fixes [SR-12842](https://bugs.swift.org/browse/SR-12842).
PR #20528 was merged yesterday, which inserts an `unreachable` in
functions with uninhabited parameters. Unfortunately this means any
statement in the function body, even ones that themselves are
never-returning or don't have any executable code, cause the warning.
Silence the warnings by deleting the bodies of these functions.
- Fix error in `last(where:)` example
- Improve MemoryLayout, UnsafePointer, and integer operator discussions
- Clean up ranges and random APIs
- Revisions to overflow operators and the SignedNumeric requirements
- Standardize on 'nonoptional' in remaining uses
As a general rule, it is safe to mark the implementation of hash(into:) and _rawHashValue(seed:) for @_fixed_layout structs as inlinable.
However, some structs (like String guts, Character, KeyPath-related types) have complicated enough hashing that it seems counterproductive to inline them. Mark these with @effects(releasenone) instead.
This includes various revisions to the APIs landing in Swift 4.2, including:
- Random and other randomness APIs
- Hashable changes
- MemoryLayout.offset(of:)
This implements the new last(where:), and lastIndex(of/where:) methods as
extensions on `BidirectionalCollection`, which partially implements SE-204.
The protocol requirements for `Sequence` and `Collection` as described
in the proposal need to wait until there's a solution for picking up the
specialized versions in types that conditionally conform to `BidirectionalCollection`.
