NSObject defines its own interface for hashing and equality. Subclasses must implement custom hashing by overriding the hash property, or NSSet and NSDictionary will not work correctly.
Unfortunately, we currently define NSObject.hashValue and NSObject.hash(into:) as overridable, which leads people to accidentally override one of these instead of hash. hashValue is explicitly declared open, while hash(into:) is automatically synthesized as such.
Making hashValue non-open is a potentially source breaking change, but we can at least provide an explicit, non-overridable definition for hash(into:), and update the documentation to explain the contract.
* 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
dispatch_source_create is marked up as non-null but can actually return
null in programming error issues. In order to maintain the nullabilty
contract, these issues will now cause the overlay to assert and crash
rather than return a null pointer out of a non-null call.
Resolves: <rdar://problem/39937177>
The current behavior is the default you get "for free" from
MutableCollection so there's no good reason for accessing the std lib
file directly, and it requires access to std lib internals to do so.
* 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.
...instead of relying on the one in the overlay in pre-4.2 versions of
Swift. This caused crashes in deserialization, which (deliberately)
doesn't respect availability.
There are three changes here:
- Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay.
- Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from
the underlying UIKit framework. (This is the nested name.)
- Ignore the unavailability messages for those two constants in
pre-4.2 Swift, since we're now relying on them being present.
The latter two, the compiler changes, can go away once UIKit's API
notes no longer specify different pre-4.2 behavior, but meanwhile we
need to keep compatibility with the SDKs released in Xcode 10b1.
https://bugs.swift.org/browse/SR-7879
* [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
