[ClangImporter] Use SwiftImportAsNonGeneric. #6962
Conversation
|
This is technically a breaking change for any third-party subclasses of the classes listed here; do you think we need to hide it behind an Additionally, allowing someone to use this in the "SwiftVersions" section is probably going to be a problem trying to interoperate across Swift 3 and Swift 4... |
lib/ClangImporter/ImportDecl.cpp
Outdated
| decl = decl->getSuperClass(); | ||
| } | ||
| return false; | ||
| return decl->hasAttr<clang::SwiftImportAsNonGenericAttr>(); |
There was a problem hiding this comment.
The existing code explicitly looked up the superclass chain. Does clang:: SwiftImportAsNonGenericAttr actually get inherited by subclasses or are we changing behavior here? I suspect it's the latter (which the SBElementArray addition implies), but that makes this a source-compatibility break for Objective-C APIs that subclass NSMutable<something>.
In Swift 3 compatibility mode, should we follow the superclass chain here?
There was a problem hiding this comment.
It does not get inherited, which I think is the desired behavior going forward, but yeah, maybe it's a good idea for Swift 3 compatibility mode to walk the superclass chain.
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)
jrose-apple
force-pushed
the
SwiftImportAsNonGeneric
branch
from
2af0dc8 to
4eafd45
Compare
|
Revised to preserve the entire-hierarchy behavior in Swift 3 mode, and noted in the commit message that there's also a big problem with mix-and-match code that I'll need to deal with down the line. What do you think now, Doug? @swift-ci Please test |
|
Yeah, I think this is the right approach so we don't break Swift 3 code yet can do something more intentional for Swift 4. |
Add support for the new 'SwiftImportAsNonGeneric' API note (apple/swift-clang#70 in upstream-with-swift), then replace a hardcoded set of class hierarchies to import as non-generic with explicit annotations in Foundation's API notes...and the one subclass of any of these types outside Foundation, ScriptingBridge's SBElementArray.
Swift side of rdar://problem/28455962.
rdar://problem/31226414