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
We do this in a more general way higher up in the constraint
solver. Filtering out methods in name lookup only hurts
diagnostics.
In fact I don't think this behavior was intentional at all,
since the code in question was originally written in 2013
before a lot of the more recent member lookup and diagnostic
code was added.
This does break source compatibility though, but in a minor
way. See the change to the CoreGraphics overlay. Again,
though, I think this was an accident and not intentional.
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
