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.
These protocols were introduced to work around the problem where
compiler could not correctly handle instance of multiple @available
attributes (one for the language version and another for teh OS version)
applied to the same member.
Now that the compiler issues has been fixed, it is the right time to get
rid of the workarounds.
Addresses: <rdar://problem/36556261>
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.
* Make the underlying builtins for FP + Vector match Integer.
For stdlib integer types, these are named `_value` and `init(_ _value: Builtin.xxx)`. This patch adopts the same scheme for stdlib floating point and SDK overlay vector types, and removes a legacy init for integers that was only needed to support them. There should be no changes visible outside of the stdlib, and no functional change within the stdlib; the naming of some implementation details is simply more uniform now.
* Updates to tgmath functions for CGFloat
These changes bring CGFloat in line with the other FloatingPoint types. Some of this stuff is now defined at the protocol level, so we can get rid of it at the concrete type level. A couple other functions have been deprecated for all types, with protocol or tgmath replacements.
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
It looks like we exposed a bunch of Metal APIs to Swift 3 that we
didn't mean to; at this point it would be a source-breaking change to
hide them. Oops.
- When a count was part of the format string, we looked at the
wrong character when forming the count.
- The OSLF_CMD_TYPE_DATA command type expects a pointer preceded
by a OSLF_CMD_TYPE_COUNT command, not 'count' bytes inline.
Fixes <rdar://problem/38080623>.
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.
