- 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'
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.
