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
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.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
This ensures that blocks that come from `DispatchWorkItem`s will
function correctly.
The only exception is __dispatch_barrier_sync() as the block passed to
that call is not `@convention(block)` so it doesn't matter.
Fixes SR-2246.
String.init(format:locale:arguments:) contained a check to make sure
that the format string didn't try to format more arguments than were
actually passed. However, the check didn't guarantee safety (since the
format specifiers didn't have to match the *type* of the passed
argument) and contained bugs such as
https://bugs.swift.org/browse/SR-1378. Since the check was not a
guarantor of safety and was wrong, it is hereby removed.
If checks are to be reintroduced, they should both be correct and
guarantee complete safety. Doing this check correctly is a nontrivial
job (the code in Clang to parse such specifiers is well over 500 lines),
and should be taken on as a distinct project.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
