A Decimal value with _length 0 and _isNegative set to 1 is interpreted as a NaN. The 'negate()' function however, flipped the _isNegative flag without regard for the _length 0 case. This meant that -0 would become NaN. The fix checks for the _length 0 special case. In NSDecimalSubtract() the same check was performed. Since this now happens in negate(), it is removed from the NSDecimalSubtract() function.
Address an exclusivity violation in Data's Iterator.next() by changing two private
'let' stored properties to be 'var'.
Making the properties 'var' changes code generation of next() so that the stored
properties are read independently of the other contents of the struct. This
prevents an exclusivity violation when reading '_endIdx' and '_data' while
simultaneously mutating '_buffer' with the call to withUnsafeMutablePointer().
The 'let' pattern is an idiom we would eventually like to support (see SR-7396),
but for now we need to remove the exclusivity violation.
DateComponents has a number of exclusivity warnings that all result from the same idiom
for applying mutation in computed properties:
public var era: Int? {
get { return _handle.map { _getter($0.era) } }
set { _applyMutation { $0.era = _setter(newValue) } }
}
Here _applyMutation() is a mutating method, so it requires exclusive access to 'self'
for the duration of the call. However, calling the _setter() method in the block
requires access to read 'self', which conflicts with the already in-progress modifying
access begun by _applyMutation().
A fix is to change _setter() to be a static function, so it doesn't require access to
'self'.
Now that Array and Dictionary conform to Hashable, we need to make sure that their bridged counterparts provide the same hash values when converted to AnyHashable.
This allows them to be used in generic arguments for NSArray et al.
We already do this for the ones that wrap bridged values (like
NSString/String), but failed to do it for objects that /weren't/
bridged to Swift values (class instances and protocol compositions),
or for Error-which-is-special.
In addition to this being a sensible thing to do, /not/ doing this led
to IRGen getting very confused (i.e. crashing) when we imported a
Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol
descriptors for imported protocols at all, because it's possible we
weren't able to import all the requirements. But that's a separate
issue.)
https://bugs.swift.org/browse/SR-6844
Despite their similar names and uses, these protocols no longer share
much functionality - the former is used to take @objc enums defined in
Swift that conform to Error and expose them as NSErrors, and the
latter handles NS_ERROR_ENUM C enums, which get imported into Swift as
a wrapper around NSError. We can actually simplify them quite a bit.
- Eliminate base protocol __BridgedNSError, which no longer provides
any implementation for _BridgedStoredNSError.
- Eliminate default implementations that match what the compiler would
synthesize.
- Adopt recursive constraints and where-clauses on associated types
(and update the Clang importer to handle this).
- Collapse signed and unsigned default implementations when reasonable.
- Fold _BridgedStoredNSError's _nsErrorDomain into the existing public
requirement CustomNSError.errorDomain.
rdar://problem/35230080
This can eventually be made more efficient by avoiding copies in all the
callees, but this is the minimal fix. Remove an unnecessary bit of
reverse-dependency on the Foundation overlay while we're here.
rdar://34222540
Deprecated the `PlaygroundQuickLook` enum and `CustomPlaygroundQuickLookable`
protocol. These are being targeted for removal in Swift 5, so we want to
unconditionally deprecate them now to encourage use of
`CustomPlaygroundDisplayConvertible` instead.
This commit includes deprecated the various `CustomPlaygroundQuickLookable`
conformances across the standard library and overlay libraries.
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
clang is miscompiling some swiftcall functions on armv7s.
Stop using swiftcall in some places until it is fixed.
Reverts c5bf2ec (#13299).
rdar://35973477
NSString has a stricter concept of equality than Swift’s String, so it is possible to construct NSDictionary/NSSet instances that contain duplicate keys according to Swift’s definition of string equality. This change improves how we handle these cases by coalescing the duplicate keys (keeping a single value).
rdar://problem/35995647
* Remove a bunch of Default(Bidirectional|RandomAccess)Indices usage from stdlib and test
* Remove some DefaultRandomAccessIndices and IndexDistance usage from Foundation
* Remove no-longer-used internal type in Existentials.swift
* Get rid of indicesForTraversal
Inserting and removing a single Unicode.Scalar in a CharacterSet must not
attempt to create a Range<Unicode.Scalar> because the upperBound value might
not always be a valid UnicodeScalar.
This fixes a regression to the fix for SR-2988.
