Generic Objective-C classes with this annotation will be imported as
non-generic in Swift. The Swift 3 behavior hardcoded a certain set of
class /hierarchies/ as permanently non-generic, and this is preserved
in Swift 3 mode.
Actually using this API note in a versioned way (as opposed to just
marking the class non-generic in all language versions) will cause
horrible source compatibility problems in the mix-and-match cases,
where Swift 3 code presents a non-generic type that Swift 4 expects to
be generic or vice versa. Fixes for this will come later; right now
it's more important to add support for the feature at all.
To avoid unwanted changes in Swift 4, this commit also adds API notes
to make any existing classes in the previously-hardcoded set continue
to import as non-generic even in Swift 4. The difference is that
/subclasses/ of these classes may come in as generic. (If we want to
make a change here, that can be a separate commit.)
rdar://problem/31226414 (Swift side of rdar://problem/28455962)
In the SDK shipped with Swift 3, NSXMLNodeKind's enumerator
NSXMLDTDKind was mistakenly annotated with `NS_SWIFT_NAME(DTDKind)`
instead of `NS_SWIFT_NAME(dtd)`. We'd like to fix that in a later
version of the SDK, but we need to maintain Swift 3 compatibility on
the off-chance someone is using the bad name. If we /do/ decide to
change this, we can undo this change (going back to an API note
SwiftName of 'dtd') and add a Swift-3-versioned SwiftName of 'DTDKind'
instead.
While the second argument to NSFastEnumeration's
countByEnumerating(with:objects:count:) really shouldn't be nil, it's
possible someone got away with it in Swift 3.
Follow-up for rdar://problem/25846421.
* [ClangImporter] Remove importer-based NS stripping.
As Tony puts it, in the end we wound up with more Foundation
declarations imported as members or keeping "NS" than those that
dropped it, and any further decisions will be made on a case-by-case
basis. Move all of the existing cases of prefix-stripping into
Foundation's API notes and drop the logic from the compiler.
Tested by dumping the generated interface for Foundation and its
submodules for both macOS and the iOS simulator, and comparing the
results. A few cases did slip through here because of the interaction
between "SwiftName" and "Availability: nonswift".
The next commit will re-add "NS" to some stragglers that we missed.
rdar://problem/26880017
* APINotes: Add "NS" back to a few types.
NSKeyedUnarchiverDelegate
NSKeyedArchiverDelegate
NSTextCheckingTypes
NSBinarySearchingOptions
NSEnumerationOptions
NSSortOptions
More rdar://problem/26880017
* Remove now-redundant SwiftNames from API notes.
No change observed in the generated interface of Foundation and its
submodules.
Finishes rdar://problem/26880017.
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
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.
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.
When an Objective-C class type is annotated with the swift_bridge
value type, bridge it to the named type. Use API notes on Foundation
rather than special cases.
For Objective-C classes where bridging was baked into the Clang
importer (NSString, NSArray, NSDictionary, NSSet), add API notes to
put the appropriate swift_bridge attribute on these Objective-C
classes.
Note: requires Clang update.
Rather than managing API notes directly in the Clang importer, tell
Clang where to find the API notes files and let it map them directly
to attributes. Then, use the existing attribute-mapping
mechanisms---with minor extensions for cases where Clang previously
didn't map some Swift-specific API notes---to get at that information.
There is a minor regression where we can no longer apply API notes to
declarations that don't have a specific Clang declaration. The
specific example (NSError's inherited init()) comes from
rdar://problem/21042412; we've regressed here, but the correct fix is
(and has always been) on the Objective-C side
(rdar://problem/19977891).
Finishes rdar://problem/24447420.
Like decodeTopLevelObjectOfClass(_:forKey:), this API works very nicely
as a generic method in Swift, and this one is actually the one we expect
to be commonly used. One thing to note here is that these methods are
stricter than their ObjC counterparts: they will do a forced checked cast
even when the unarchiver does not use "secure" coding.
This depends on the previous commit; without it, we do not actually
enforce type safety for these methods.
The API notes change is to make the non-generic version of this method
unavailable so that it does not participate in overload resolution.
Without this we prefer the non-generic method unless there's a contextual
type for the result. I've filed rdar://problem/22243198 to track taking
this out once Foundation has updated their headers.
rdar://problem/17060110 (again)
Swift SVN r31154
Then use that to ban NSError.init(), because it doesn't create a valid
NSError. In the long run Foundation will hopefully add this to their
headers, but they can't yet (rdar://problem/19977891).
rdar://problem/21042412
Swift SVN r28881
<rdar://problem/17902944> UIView's motionEffects property should never return 'nil'
<rdar://problem/17971360> [factor-init] SKPhysicsJointPin's factory method is not converted to a Swift API initializer
<rdar://problem/18553910> #IUO UICollectionViewUpdateItem properties
<rdar://problem/18875692> NSEntityDescription subentities/subentitiesByName should be marked optional
<rdar://problem/18919879> Swift: NSTableView's preparedCellAtColumn(_:row:) should return an optional
<rdar://problem/18940072> NSPredicate's init(format:) should not be optional
<rdar://problem/18987481> NSURLRequest without NSURL crashes Swift
<rdar://problem/19034448> UIPrintInfo’s -init is banned, should use +printInfo
<rdar://problem/19147412> NSUserInterfaceItemIdentification declares identifier as a non-optional String and it should be optional or IUO
<rdar://problem/19347931> Declaration of a parameter in Cocoa API in Swift is wrong (NSDateFormatter)
+ additions to the WatchKit audit
+ additions to HealthKit and HomeKit.
Swift SVN r24630
Here, we mark the null_resettable properties as explicit "U".
Fixed UIColor and NSColor's initWithCGColor as returning an optional (radar://18420272)
Fixed fontDescriptorWithSymbolicTraits (rdar://problem/18812268)
Contains audit for NSXMLParserDelegate (rdar://problem/18227344)
+ a few other newly audited APIs
Swift SVN r23698
- Mark more initializers as non-optional.
<rdar://problem/18559511> Audit the list of UIKit symbols that marked as returning optional
<rdar://problem/18559660> Audit the list of AppKit symbols that marked as returning optional
<rdar://problem/18559676> Audit the list of Foundation symbols that marked as returning optional
<rdar://problem/18559730> Audit the list of Scenekit symbols that marked as returning optional
- NSMenu.popUpMenuPositioningItem (radar://18505688)
- Remove NSXMLParserDelegate audit since it leads to crashes (radar://18227344)
- UICollectionViewController collectionView should not be optional (radar://18508177)
Swift SVN r22570
- Make NSZone functions unavailable radar://16688847
- Distributed Objects subsystem should not be imported into Swift radar://16689104
- NSCalendarDate is available in Swift, but deprecated radar://16689207
- Do not import NSMethodSignature class and related methods radar://16689329
- NSInvocationOperation should be unavailble in Swift radar://17921785
Swift SVN r22090
