* 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.
It was a warning because I didn't want to break anything when I first
added the check, but we've been warning-free for a while now. Let's
keep it that way.
This changes how we import CGPDFContextEndPage to be
CGContext.endPDFPage(), instead of .endPage() which conflicts with
another CGContext function. Also does .beginPDFPage() for consistency,
which is consistent with e.g. drawPDFPage().
Note that the Swift name here is deliberately different from the
Objective-C name. It is the authorization that changed, even though
the argument is an authorization status.
- (void)locationManager:(CLLocationManager *)manager
didChangeAuthorizationStatus:(CLAuthorizationStatus)status;
optional func locationManager(_ manager: CLLocationManager,
didChangeAuthorization status: CLAuthorizationStatus)
rdar://problem/26586048
The problem here is that there isn't an obvious way to force a CMake
reconfiguration when you need to add new apinotes. This dates back to
when we (internally) had the apinotes in a separate repo, but that
hasn't been the case for a long time.
We're still not using a /normal/ CMake add_subdirectory for these
because we compile the apinotes as part of building overlays for
frameworks that have both overlays and apinotes, and I didn't want to
touch any of that stuff right now.
That is, import something like 'CGColorCreateGenericGray' as
"CGColor.init(gray:alpha:)" rather than "CGColorRef.init(gray:alpha:)".
Since we print the type name in diagnostic text and in fix-its, it's
important to use the name that Swift sources use.
Finishes rdar://problem/26347297.
