Where we have rethrowing versions of functions that have typed-throws
counterparts that are only retained for ABI compatibility, wrap them
in `#if !$Embedded` so they aren't compiled into the Embedded version
of the standard library. This eliminates warnings about this code,
which cannot actually be used with arbitrary errors anyway.
Usually this function is inlined anyway. But if it is not (and that can happen), it has a dramatic performance impact. Also, usually code size regresses if this function is not inlined.
The stdlib is always built with NoncopyableGenerics enabled, so `#if
$NoncopyableGenerics` guards in non-inlinable code are superfluous.
Additionally, the stdlib's interface no longer needs to support compilers
without the feature, so the guards in inlinable code can also be removed.
https://github.com/swiftlang/swift/pull/72612 can be reverted because it is no
longer necessary for the interface of the stdlib to be compatible with
compilers without `$TypedThrows` support.
Allow `@_implements` to be expressed in an extension of the protocol in
which the associated type is defined. Use this to uncomment an
intended use of `@_implements` in `Sequence` that could be used to
replace a longstanding hack for associated type inference.
Since this change means that the standard library module interface
won't be accepted by older compilers, introduce a suppressible feature
ssociatedTypeImplements` that covers the use of `@_implements` on type
declarations. This will hide the `@_implements` attribute from older
compilers.
Replace the hackish use of `@_disfavoredOverload` with the more principled
use of `@_silgen_name` for the entrypoint we are maintaining, then rename
these functions in source to `__rethrows_map` to indicate what they're for.
While here, make them `throws` instead of `rethrows`. The ABI is the
same, and `throws` allows us do avoid to do/catch tricks with rethrows
functions.
Adopt typed throws for the `map` operation to propagate thrown error
types through the `map` API. This is done in a manner that is backward
compatible for almost all cases:
* The new typed-throws entrypoint is `@_alwaysEmitIntoClient` so it
can back-deploy all the way back.
* The old `rethrows` entrypoint is left in place, using
`@usableFromInline` with `internal` so it is part of the ABI but not
the public interface, and `@_disfavoredOverload` so the type checker
avoids it while building the standard library itself. The old
entrypoint is implemented in terms of the new one.
Note that the implementation details for the existential collection
"box" classes rely on method overriding of `_map` operations, and the
types are frozen, so we don't get to change their signatures. However,
these are only implementations, not API: the actual API `map`
functions can be upgraded to typed throws.
Note that this code makes use of a known hole in `rethrows` checking
to allow calling between `rethrows` and typed throws. We'll need to do
something about this for source-compatibility reasons, but I'll follow
up with that separately.
NFC.
We know maxLength must be positive and non-zero, and therefore, i += 1 will be the next index until we reach maxLength, in which case the result is 0. Rather than perform a modulo, which requires division, every time, we can just reset i when it reaches the end of the buffer.
With `NoncopyableGenerics` enabled, we currently lose some ability for
associatedtype inference to find a suitable type witness based on a
value witness. (rdar://118998138)
The stdlib accidentally uses that inference for Sequence.Element,
due to the default witness for `_customContainsEquatableElement`
mentioning `Iterator.Element` whereas the requirement only states
`Element`.
The requirement machine does not allow 'where' clauses to reference
typealiases defined in protocol extensions.
These should probably be removed entirely since they're not useful
anymore, but I'd rather that decision was made by the stdlib folks.
* First draft of incorporating material from #38891
* Apply suggestions from Alex's review
Co-authored-by: Alex Martini <amartini@apple.com>
* Rephrase suggested by Alex.
* Remove redundancy re: "don't replace buffer".
* Apply changes from editorial review.
* Apply Sequence edits (a3a3ff1) to MutableCollect'n
* Remove errant space.
Co-authored-by: Guillaume Lessard <glessard@users.noreply.github.com>
Co-authored-by: Chris Adamson <cadamson@apple.com>
Co-authored-by: Alex Martini <amartini@apple.com>
Co-authored-by: Guillaume Lessard <glessard@users.noreply.github.com>
- clarify the requirement that the entire collection must be accessible
- clarify the requirement surrounding subsequences / slices
- add parameter descriptions
- specify that buffer cannot be replaced
This iteration ranged from `buffer.startIndex` to `buffer.count`, rather than to `buffer.endIndex`.
Using `buffer.indices` is a better solution in any case.
Array’s _copyContents implementation traps if given too small a buffer. This prevents Sequence._copyContents from being used to speed up copying data into discontiguous memory. (We have to require a Collection conformance and run _copyContents on slices instead).
Document the underlying requirement.
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.
calls over arrays created from array literals. This enables optimizing
further the output of the OSLogOptimization pass, and results in
highly-compact and optimized IR for calls to the new os log API.
<rdar://58928427>
* [stdlib] Update complexity docs for seq/collection algorithms
This corrects and standardizes the complexity documentation for Sequence
and Collection methods. The use of constants is more consistent, with `n`
equal to the length of the target collection, `m` equal to the length of
a collection passed in as a parameter, and `k` equal to any other passed
or calculated constant.
* Apply notes from @brentdax about complexity nomenclature
* Change `n` to `distance` in `index(_:offsetBy:)`
* Use equivalency language more places; sync across array types
* Use k instead of n for parameter names
* Slight changes to index(_:offsetBy:) discussion.
* Update tests with new parameter names
We would like to eventually extend Array, Dictionary, and Set to support move-only element types when the language does. To that end, we need to get the `consuming`-ness of protocol requirements on Sequence, Collection, and related protocols right for forward compatibility so that a future version of Swift that extends these types to support move-only data structures remains ABI- and API-compatible with older versions of the language. Mark requirements as `__consuming` where it would be necessary for a move-only implementation of one of these types.
