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
- 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.
Without this change, the Hashable synthesizer attempts to add hash(into:) methods directly on CF types, which (somewhat unsurprisingly) fails with assertion below. (This situation is unique to CF types, which are imported with an implicit _CFObject conformance; we usually have an extension context or a non-imported type decl in which to put the derived methods.)
Assertion failed: (!decl->isForeign() && "Use getForeignMetadataLayout()"), function getClassMetadataLayout, file /Users/klorentey/Swift/swift/lib/IRGen/MetadataLayout.cpp, line 83.
0 swift 0x000000010ccd29c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 swift 0x000000010ccd30d6 SignalHandler(int) + 694
2 libsystem_platform.dylib 0x00007fff600e0d9a _sigtramp + 26
3 swift 0x000000010e04f1ed cmark_strbuf__initbuf + 122440
4 libsystem_c.dylib 0x00007fff5ffa6f79 abort + 127
5 libsystem_c.dylib 0x00007fff5ff6f090 basename_r + 0
6 swift 0x00000001096e8f95 swift::irgen::IRGenModule::getClassMetadataLayout(swift::ClassDecl*) + 53
7 swift 0x00000001095b9e25 swift::irgen::emitVirtualMethodValue(swift::irgen::IRGenFunction&, llvm::Value*, swift::SILDeclRef, swift::CanTypeWrapper<swift::SILFunctionType>) + 133
8 swift 0x00000001095ba252 swift::irgen::emitVirtualMethodValue(swift::irgen::IRGenFunction&, llvm::Value*, swift::SILType, swift::SILDeclRef, swift::CanTypeWrapper<swift::SILFunctionType>, bool) + 690
9 swift 0x00000001096bef49 swift::SILInstructionVisitor<(anonymous namespace)::IRGenSILFunction, void>::visit(swift::SILInstruction*) + 33497
10 swift 0x00000001096b3067 swift::irgen::IRGenModule::emitSILFunction(swift::SILFunction*) + 8055
11 swift 0x00000001095c8d8b swift::irgen::IRGenerator::emitLazyDefinitions() + 1051
12 swift 0x000000010968eb16 performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule> >, llvm::StringRef, swift::PrimarySpecificPaths const&, llvm::LLVMContext&, swift::SourceFile*, llvm::GlobalVariable**, unsigned int) + 1382
13 swift 0x000000010968f05e swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule> >, llvm::StringRef, swift::PrimarySpecificPaths const&, llvm::LLVMContext&, unsigned int, llvm::GlobalVariable**) + 94
14 swift 0x000000010952cfc0 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 15488
15 swift 0x0000000109528332 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2962
16 swift 0x00000001094e4848 main + 2328
17 libdyld.dylib 0x00007fff5feecc41 start + 1
Stack dump:
[…]
1. While emitting IR SIL function "@$SSo10CGColorRefas8HashableSCsACP4hash4intoys6HasherVz_tFTW".
for 'hash(into:)' in module 'CoreGraphics'
