The implementation-detail requirement Error._userInfo is always an
NSDictionary?. However, because this requirement is declared within
the standard library, it cannot be typed as such. So, use
'AnyObject?', comment that this is always 'NSDictionary?' in practice,
and fix up the uses.
Addresses rdar://problem/27824194 as much as we can.
Provide default implementations for all of the CustomNSError requirements:
* errorDomain: default to the name of the enum type
* errorCode: default to the same thing "_code" gets, e.g., the enum tag or
raw value
* errorUserInfo: default to empty
This makes it significantly easier to customize just one aspect of the
NSError view of an error type, e.g., just the user-info dictionary,
without having to write boilerplate for the others. This was actually
part of SE-0112, but I missed it in the original implementation and we
thought it was an amendment.
Fixes rdar://problem/23511842.
This reverts commit dc0ae675bc. The
change here (presumably the change to Foundation) caused a regression
in several of the bridging-related benchmarks, e.g.,
ObjectiveCBridgeFromNSSetAnyObjectToString, DictionaryBridge,
ObjectiveCBridgeFromNSDictionaryAnyObjectToString.
Remove the functions
_(set|dictionary)Bridge(From|To)ObjectiveC(Conditional) from the
standard library. These entrypoints are no longer used by the compiler
(thanks to generalized collection up/downcasting), so stop using them
in Foundation and in tests.
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
https://bugs.swift.org/browse/SR-2388
Use that instead of rolling it up in _SwiftTypePreservingNSNumber so that we
get the right behavior when we go to write plists.
https://bugs.swift.org/browse/SR-2381
The Objective-C type encoding of Boolean values in NSNumber is that of
BOOL, which is either signed char or _Bool depending on the
platform. _SwiftTypePreservingNSNumber was using _Bool, which led to
inconsistencies when bridging vs. creating an NSNumber directly. Use
BOOL consistently.
Fixes rdar://problem/27894308.
Note: we leave all of the old names in as deprecated (with a rename),
so that we don't actually break any existing source code. Fixes
rdar://problem/27778189.
`setObject:forKey:` takes a nonnull object, causing us to accidentally pass in a boxed Optional-in-an-Any from the Swift subscript's optional newValue. Fixes rdar://problem/27875914.
This API is documented in its headers to only allow being called once
for a particular domain, so we have to make sure our check for an
existing provider is synchronized with the setting.
rdar://problem/27541751
The override methods were not marked with @objc which incorrectly funneled to the abstract base class methods. In the method isSuperset(of:) it would incorrectly hit a requirement of a subclass implementation. This exposed a flaw with NSCharacterSet in which that method cannot recieve subclasses to the other CharacterSet being passed. This is being tracked via rdar://problem/27768939 which will need to be accounted for by CoreFoundation. Until such a time that can be addressed the workaround by using CFCharacterSetIsSupersetOfSet must be used with a copy passed as the other set.
This resolves:
https://bugs.swift.org/browse/SR-2307
After speaking with the current owner of Measurement, the most sensible path is to at runtime verifty the conformance of Units to a specific dimension since we cannot directly check at compile time. If at a future point in time a more specific comparitor can be added that can restrict the comparison to measurements in a specific dimension without causing equatable failures we may want to revisit this. However as it stands this preserves the most reasonable implementation of comparison of disperate measurement unit types while preserving the expected logic of conversions within that dimension.
The default implementation for comparable automatically adds >, >= etc by having == and < defined. Also the dynamic check for comparison of measurements that are convertible should traverse through the same runtime equality check instead of a static dispatch call out.
This resolves:
<rdar://problem/27556581> Measurement type defines two '==' functions
SE-0072 took implicit bridging conversions away, which regressed the ability to express NSDictionaries as dictionary literals and index them using literal keys. Address this by changing the signature of init(dictionaryLiteral:) to use Hashable and Any, and by replacing the subscript from Objective-C with one using _Hashable that does the bridging on the user's behalf. This largely restores the QoI of working with NS collections.
This allows String, Array, Dictionary, and Set to be passed as variadic arguments to Cocoa APIs like NSLog, NSPredicate, stringWithFormat:, etc. rdar://problem/27651717
This provides a hint to the proper API to use for struct Data when developers are migrating from NSData.
Purely a fixit addition (no actual functional code)
<rdar://problem/26206061> Missing fixit for Data.getBytes
This simplifies the bridging story for Notifications to their objc counterparts since the id -> Any and AnyHashable changes have now been applied (which makes the previous boxing strategy no longer needed). Previous consumers of Notification that were using String keys should still work, however any explicit dictionary types should migrate from Swift 2.2 -> Swift 3 from userInfo as [NSObject:AnyObject] to [AnyHashable:Any]. The condition of distributed notifications (in non sandboxed apps) requiring plist types still applies and will fail at runtime if incorrect types are passed into the objective-c layer, and in the case of sandboxed apps userInfo still is forbidden (this change is a non functional change in the respect to those behaviors).
Resolves the following issues:
<rdar://problem/27426757>
<rdar://problem/27561621>
<rdar://problem/27259984>
When emitting an existential erasure to Error from an archetype, use
the _getEmbeddedNSError() witness. If it produces an NSError, erase
that; otherwise, go through the normal erasure path.
Of course, make NSError and CFError implement _getEmbeddedNSError() so
this kicks in for the obvious cases as well as the more obscure ones.
Fixes the rest of SR-1562 / rdar://problem/26370984.
Imported Cocoa error types are represented by structs wrapping an
NSError. The conversion from these structs to Error would end up
boxing the structs in _SwiftNativeNSError, losing identity and leading
to a wrapping loop.
Instead, extract the embedded NSError if there is one. In the Swift
runtime, do this as part of the dynamic cast to NSError, using a (new,
defaulted) requirement in the Error type so we can avoid an extra
runtime lookup of the protocol. In SILGEn, do this by looking for the
_BridgedStoredNSError protocol conformance when erasing to an Error
type. Fixes SR-1562 / rdar://problem/26370984.
