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`.
- Make RawRepresentable Codable abstracts distinguishable
- Make the UnboundedRange example a little more user friendly
- Correct the RangeReplaceableCollection example description
- Revise CaseIterable discussion
Previously, both CountableRange and CountableClosedRange required
their bound types to be Strideable with a Stride type that conforms to
SignedInteger. Those constraints were not present on the generic
typealiases that replaced these structs. Add them back now, which
fixes the GRDB source compatibility regression.
Fixes https://bugs.swift.org/browse/SR-6907 / rdar://problem/29066394.
