The law of exclusivity now allows us to remove the safety belt of swapping out self, getting rid of the need to create an empty array. (Which eliminates a swift_retain call.)
Before this change, the ABI checker didn't complain about missing @available
attributes on new APIs if the enclosing scopes of new APIs have
availability information. Instead, we should require explicit @available attributes
for new APIs to prevent them inheriting wrong availability information from a
preexisting scope.
rdar://81719628
These were defined for both FixedWidthInteger and FixedWidthInteger & SignedInteger for source compatibility with Swift 3; the latter set probably should have been removed when we stabilized the ABI, but were not. We can't easily remove them entirely (because we need them for ABI stability now), but we can mark them unavailable so that the typechecker doesn't have to consider them..
Previously we said that a type conforming to SignedNumeric allows positive and negative values, but that's nonsense. A type conforms to signed numeric if it has a negate() operation; it doesn't even have to have a notion of positive or negative values (for examples, see complex numbers, quaternions, integers mod n, etc).
Designated types were removed from the constraint solver in #34315, but they are currently still represented in the AST and fully checked. This change removes them as completely as possible without breaking source compatibility (mainly with old swiftinterfaces) or changing the SwiftSyntax tree. Designated types are still parsed, but they are dropped immediately and a warning is diagnosed. During decl checking we also still check if the precedence group is really a designated type, but only so that we can diagnose a warning and fall back to DefaultPrecedence.
This change also fixes an apparent bug in the parser where we did not diagnose operator declarations that contained a `:` followed by a non-identifier token.
`Sequence._copyContents(initializing:)` is the function relied on by
`UnsafeMutableBufferPointer` for performant initialization from Collections.
Until now, `Slice<Base: Collection>` has not had its own implementation,
and therefore fell back to the default version implemented on `Sequence`.
This implementation adds an attempted fast path, using
`withContiguousStorageIfAvailable`. If that fails, the `Sequence`
algorithm is used, as before.
This resolves https://bugs.swift.org/browse/SR-14491
- add a default implementation of MutableCollection’s
subscript(bounds: Range<_>) with the most general signature possible
- it is marked unavailable in order to prevent the
infinite recursion bug reported in SR-14848
- add a conditionally-available subscript(bounds: Range<_>) -> Slice<Self>
only when Subsequence is Slice<Self>. This will supersede
the unconditional extension that provides the same signature.
- adds a default implementation of Collection’s subscript(bounds: Range<_>)
with the most general signature possible
- it is marked unavailable in order to prevent the
infinite recursion bug reported in SR-14848
- Collections whose SubSequence is Slice<Self> still get the proper default, as intended.
`_copyContents(initializing:)` is a core method of Sequence, and it is used surprisingly often to copy stuff out of sequences. Array’s internal types currently have explicit implementations of it that trap (to prevent a performance bug due to the default iterator-based implementation. This has proved a bad idea, as not all code paths that end up calling `_copyContents` have actually been expunged — so we replaced a performance bug with a catastrophic correctness bug. 😥
Rather than trying to play whack-a-mole with code paths that end up in `_copyContents`, replace the traps with (relatively) efficient implementations, based on the ancient `_copyContents(subRange:initializing)` methods that have already been there all this time.
This resolves https://bugs.swift.org/browse/SR-14663.
I expect specialization will make this fix deploy back to earlier OSes in most (but unfortunately not all) cases.
* Use the "nearly divisionless" algorithm on all targets.
We have multipliedFullWidth available everywhere now, so we don't need to carry around the old implementation on 32b targets.
Also adds a few more benchmarks for random number generation.
* Obscure the range boundaries for some of the new random value benchmarks.
When these are visible compile-time constants, the compiler is smart enough to evaluate the division in the "nearly divisionless" algorithm, which makes it completely divisionless. That's good, but it obscures what the runtime performance of the algorithm will be when the bounds are _not_ available as compile-time constants. Thus, for some of the newly-added benchmarks, we pass the upper bound through `identity` to hide it from the optimizer (this is imperfect, but it's the simplest tool we have).
We don't want to do this for all the tests for two reasons:
- compile-time constant bounds are a common case that should still be reflected in our testing
- we don't want to perturb existing benchmark results more than we have to.
