* The buffer-pointer based init methods were passing the dispatch
data default destructor in such a way that the
@convention(block)-ness was lost. This leads to a thunk being passed
to dispatch instead of NULL. Subsequently, dispatch would reference
rather than copy the provided data.
Fixes:
SR-2050 (<rdar://problem/27293973>)
* Fix DispatchSourceSignal initialisation such that it no longer
registers for the wrong source type.
* Remove (group:) option from DispatchWorkItem, introduce group
options to `.async` methods that accept DispatchWorkItem.
* Rename `DispatchSourceType` to `DispatchSourceProtocol`
* Rework DispatchQueue attributes and flags into a less confusing
approach.
* Fixes:
SR-1817, SR-1771, SR-1770, SR-1769
<rdar://problem/26725156> <rdar://problem/26873917>
<rdar://problem/26918843> <rdar://problem/26810149>
<rdar://problem/27117023> <rdar://problem/27121422>
<rdar://problem/27236887> <rdar://problem/27337555>
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 46a9f57329.
This broke Swift CI, OSS incremental RA:
./swift/stdlib/public/SDK/Foundation/TimeZone.swift:228:45: error: 'NSTimeZone' is not implicitly convertible to 'TimeZone'; did you mean to use 'as' to explicitly convert?
return lhs._wrapped.isEqual(to: rhs._wrapped)
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 9c1f21bdf0.
This breaks swift-ci for everyone:
stdlib/public/SDK/Foundation/Calendar.swift:426:74: error: 'DateInterval' is only available on iOS 10.0 or newer
public func dateInterval(of component: Component, for date: Date) -> DateInterval? {
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
Second pass at updates for SE-0086 feedback
<rdar://problem/26892977> Make sure NSOrderedSet keeps its NS
<rdar://problem/26880016> NSBundleResourceRequest should keep its NS
<rdar://problem/26892958> Make sure NSAttributedString keeps its NS
<rdar://problem/26653694> NSCoder.decodeTopLevelObjectForKey does not follow naming guidelines
<rdar://problem/27355801> Foundation should have a structural type for TextCheckingResult
<rdar://problem/26770611> NSExpression naming is a bit awkward in swift
<rdar://problem/26653451> NSCoder encodeDataObject is misleading
<rdar://problem/26653653> NSCoder decodeObjectOfClass is redundant
This renames several APIs off of CGAffineTransform, CGPoint, CGSize,
CGColor, CGContext, CGRect, and CGColorSpace to have more consistent
names and Swifty names, in accordance with the Swift API Design
Guidelines.
At the same time, we drop many of the special mutating variants from
the overlays, as they are not typical CG usage and a historical
artifact. Test cases added for each.
Introduce typed accesses for the error types of AVFoundation,
CloudKit, Contacts, and CoreLocation. While here, fix the API notes
for the Contacts framework, which had an embarrassingly-wrong file
name ;)
Introduce bridging of NSError to ErrorProtocol, so an Objective-C API
expressed via an "NSError *" will be imported using ErrorProtocol in
the Swift. For example, the Objective-C method:
- (void)handleError:(NSError *)error userInteractionPermitted:(BOOL)userInteractionPermitted;
will now be imported as:
func handleError(_ error: ErrorProtocol, userInteractionPermitted: Bool)
This is bullet (3) under the proposed solution of SE-0112. Note that
we made one semantic change here: instead of removing the conformance
of NSError to ErrorProtocol, which caused numerous problems both
theoretical and actual because the model expects that an NSError
conforms to ErrorProtocol without requiring wrapping, we instead limit
the ErrorProtocol -> NSError conversion that would be implied by
bridging. This is defensible in the short term because it also
eliminates the implicit conversion, and aligns with SE-0072, which
eliminates implicit bridging conversions altogether.
These apinotes will swift_private many of the bounding box methods,
and adjust the overlays appropriately. Those APIs have better
alternatives provided by the overlays, and thus shouldln't be exposed.
The Clang attribute allows one to state that a particular enumeration
type describes an error, and associates it with a particular domain
constant. However, due to lack of API notes support, this attribute
wasn't actually getting used. Instead, we had a number of explicit
extensions to enum types to make them conform to the _BridgedNSError
protocol explicitly.
Now that we have API notes, use them to make these enums into error
enums with the appropriate domain, so that the Clang importer will
synthesize the _BridgedNSError conformances. Then, remove all of the
explicit conformances---and with them, the overlays for 12 frameworks.
There is a small fix to more eagerly consider these conformances as
"used" if an expression is formed with the error enum as a value
type. This better ensures that the conformances will be available at
runtime when needed.
This cleanup is needed to implement SE-0112 (NSError bridging),
although it is useful by itself.
Addresses the following issues:
rdar://problem/25992816 -[NSUserDefaults registerDefaults] is being imported as NSUserDefaults.register(), which is confusing
rdar://problem/26291437 UserDefaults has 'setURL(forKey:)' instead of 'set(_:forKey:)'
rdar://problem/26375229 FileManager overlay has old naming
rdar://problem/26090891 NSBundle methods that are overridden in the apinotes incorrectly handle the first argument pattern
rdar://problem/26271340 struct URL initializer for fileURLWithFileSystemRepresentation is incorrectly named'
rdar://problem/26443640 XMLDTDNode.Kind conflicts with XMLNode.Kind and should be renamed to XMLDTDNode.DTDKind
rdar://problem/26500390 registerUndoWithTarget in overlay not updated for new API names
rdar://problem/26653451 NSCoder encodeDataObject is misleading
rdar://problem/26653653 NSCoder decodeObjectOfClass is redundant
rdar://problem/26653694 NSCoder.decodeTopLevelObjectForKey does not follow naming guidelines
rdar://problem/26656299 SocketNativeHandle should be a hoisted type to SocketPort
https://bugs.swift.org/browse/SR-1903
.strongMemory and .objectPersonality happen to be the default settings
in their respective subgroups, but that doesn't mean they should be
omitted from the option set.
