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.
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
Some files accidentally /renamed/ the enums using SwiftName rather than
associating them with an error domain constant. Amazingly, we've gotten
no complaints about this.
We could support this in the future but right now it's causing problems.
There's also a potential ambiguity issue here where a protocol and class
could have the same name.
In addition to updating the importer, remove the two entries from the
CryptoTokenKit API notes that were trying to use this feature.
rdar://problem/27990168
We don't yet support nested types for the target of swift_name, which
is a very unfortunate omission. Instead, use un-qualified names in the
apinotes, which default to the decl's context, which in this case
fortunately interacts with swift_newtype to end up in the properly
nested struct in Swift proper. Gross.
CoreText is below Foundation in the framework stack, so its error enum
uses a CFStringRef constant as its domain instead of an NSString. The
importer doesn't know how to handle that yet, so for now, just don't
import CTFontManagerError as a first-class error type.
rdar://problem/27722004
* [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.
* 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>)
