Clean up the submodules in visualc to not export all imported modules.
The one special case is `vcruntime` which re-exports `SAL` due to a
dependency in the headers. The import of `visualc` however will
re-export all submodules to keep the current behaviour. This is
required to get the ARM64 SDK building on newer MSVC toolsets.
Windows ARM64 is a LLP64 platform, which means that `unsigned long` is a
32-bit value. This was already mapped properly for x86_64, but somehow
had missed ARM64. This repairs that which is required for building the
standard library.
* Audit and correct AsyncSequence Sendability
* Annotate availability on Sendable conformances for AsyncSequences
* Fix typo of Sendable.Iterator
* Correct tests to use sendable builders
* Add @preconcurrency annotations and fixup one remaining missing @Sendable case
* Move preconcurrency to correct syntactical position
* Use unchecked Sendable conditional conformance instead of marking all internals as preconcurrency and sendable
* Use unchecked Sendable conditional conformance instead of marking all internals as preconcurrency and sendable for dropWhile
* claim ABI changes for marking of @preconcurrency as expected
_Concurrency is not used in the module, and having it as a dependency causes a ninja error when trying to build stdlib without `-D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY=YES`:
```
ninja: error: 'stdlib/private/OSLog/swift_Concurrency-swiftmodule-macosx-arm64', needed by 'stdlib/private/OSLog/OSX/arm64/OSLogTestHelper.o', missing and no known rule to make it
```
`String.UnicodeScalarView` currently lacks proper index validation in its `index(after:)` and `index(before:)` methods, leading to out-of-bounds memory accesses when index navigation methods in this view are given invalid indices.
(Also see https://github.com/apple/swift/pull/41598 and https://github.com/apple/swift/pull/41417)
rdar://89498541
`String.index(before:)` (and methods that rely on it, such as `Substring.index(before:)`, `.distance(from:to:)` etc.) does not currently verify that the given index falls before the `endIndex` before aligning it to a scalar boundary. This allows an out-of-bounds memory access when the provided index points to a position beyond the end of `self`’s storage.
Additionally, the `i > startIndex` check needs to be done after scalar alignment, not before, as alignment can round the index down to `startIndex`.
rdar://89497074&89495373
`IndexDistance` is an artifact of ancient history — it used to be an associated type of Collection in the Swift 3 era. The Collection requirement got replaced with a deprecated typealias of Int in Swift 4, the same release that re-introduced the Collection conformance for String.
However, the typealias declaration for String.IndexDistance has fallen through the cracks. It was accidentally left un-deprecated and it’s still actively mentioned in String API declarations to this day. (These usages leak into the API docs, which can be a source of unnecessary confusion.)
Let’s put an end to this and add the missing deprecation attribute, replacing `IndexDistance` usages with `Int`.
While we’re here, also bring `String.index(_:offsetBy:)` and `String.index(_:offsetBy:limitedBy:)` in sync with their declarations in Collection by renaming the second argument from `n` to `distance`.
(These method declaration changes do get emitted into .swiftinterface files, but they aren’t breaking any client code — the argument names are only relevant to the docs (and the method implementation). They do not affect callers of these functions.)
Currently, the default implementations of the various `_failEarlyRangeCheck` forms contain several _precondition invocations, like this:
```
@inlinable
public func _failEarlyRangeCheck(_ index: Index, bounds: Range<Index>) {
_precondition(
bounds.lowerBound <= index,
"Out of bounds: index < startIndex")
_precondition(
index < bounds.upperBound,
"Out of bounds: index >= endIndex")
}
```
Each such precondition call generates a separate trap instruction, which seems like a waste — theoretically it would be helpful to know which condition was violated, but in practice, that information tends not to be surfaced anyway. Combining these will lead to a minuscule code size improvement.
(The separate messages do surface these in debug builds, but only if these generic defaults actually execute, which isn’t often. These are not public entry points, so concrete collection types tend ignore these and roll their own custom index validation instead. From what I’ve seen, custom code tends to combine the upper/lower checks into a single precondition check. These underscored requirements tend to be only called by the standard `Slice`; and it seems reasonable for that to follow suit.)
More interestingly, the range-in-range version of `_failEarlyRangeCheck` performs two times as many checks than are necessary:
```
@inlinable
public func _failEarlyRangeCheck(_ range: Range<Index>, bounds: Range<Index>) {
_precondition(
bounds.lowerBound <= range.lowerBound,
"Out of bounds: range begins before startIndex")
_precondition(
range.lowerBound <= bounds.upperBound,
"Out of bounds: range ends after endIndex")
_precondition(
bounds.lowerBound <= range.upperBound,
"Out of bounds: range ends before bounds.lowerBound")
_precondition(
range.upperBound <= bounds.upperBound,
"Out of bounds: range begins after bounds.upperBound")
}
```
It is safe to assume that `range.lowerBound <= range.upperBound`, so it’s enough to test that `bounds.lowerBound <= range.lowerBound && range.upperBound <= bounds.upperBound` — we don’t need to check each combination separately.
Generated code has never actually initialized this field, so we
might as well remove it. Doing so mostly doesn't impact the ABI
since we don't store anything for arguments or results in the
context as part of the normal call sequence. We do need to adjust
some of the hard-coded contexts, however, such as continuation
contexts and the statically-sized context for special runtime
async functions.
