* Make _sanityCheck internal
* Make _debugPrecondition internal
* Make Optional._unsafelyUnwrappedUnchecked internal.
* Make _precondition internal
* Switch Foundation _sanityChecks to assertions
* Update file check tests
* Remove one more _debugPrecondition
* Update Optimization-with-check tests
* Add constraints to FixedWidthInteger.Stride and .Magnitude
Add the constraint that these associatedtypes themselves conform to FixedWidthInteger and to SignedInteger and UnsignedInteger, respectively. These are effectively part of the semantic requirement of the protocol already, because the requirements on .min and .max effectively force FixedWidthInteger to be twos-complement, which requires Magnitude not be Self for signed types. Also, in practice it's generally necessary to have these two constraints in order to effectively use the FixedWidthInteger protocol anyway; witness that by adding them to the protocol, we eliminate them as constraints from a number of extensions.
This also resolves https://bugs.swift.org/browse/SR-8156
Protocol name mangling didn’t always go through a path that allowed the use
of standard substitutions. Enable standard substitutions for protocol name
manglings where they make sense.
Removes ~277k from the standard library binary size.
* [Foundation] adjust inline of append and initialization functions and use _copyContents(initialzing:) to avoid performance regressions while using generic collection/sequence APIs
* Add the Array<UInt8> specialization back for append to Data
Simplify String.Index by sinking transcoded offsets into the .utf8
variant. This is in preparation for a more resilient index type
capable of supporting existential string indices.
This has one known performance regression; appending with a sequence (not an Array, but something like a Repeated<UInt8>) is slower. We aknowlege this regression and plan to offer an update later that has a specialized variation of this API that optimizes to a memset/memset_pattern. This set of changes is limited to specifically targeting ABI stability and inline characteristics of Data and leaves that optimization as a future addition.
This fixes a problem where error bridging didn't work in stripped executables using the static versions of the Swift libraries. ErrorObject.mm looks up some symbols with dlsym, but stripping makes it so it can't find those. This change makes a separate set of symbols explicitly made for ErrorObject.mm to look up, and marks them as dynamically referenced so stripping won't remove them. Longer term, we'd like a better solution for looking up these symbols, but this will do for now.
rdar://problem/39810532
- JSONEncoder.swift: tell the compiler that yes, this is supposed to
be casting to 'T' and not 'T?'.
- NSObject.swift: mark NSKeyValueObservation members explicitly @objc
and @nonobjc.
- NSStringAPI.swift: remove unnecessary @usableFromInline.
No intended functionality change.
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.
