Begin importing APIs under both Swift 3 and Swift 4 names, to produce errors #6720
Conversation
|
@milseman, does this seem like the right approach? The last commit is probably the most interesting one for now. |
lib/ClangImporter/ImportName.cpp
Outdated
| // FIXME: This is brittle. The empty version represents "newest", as in | ||
| // "newer than the current version", but ImportNameVersion::Swift4 is | ||
| // a specific new version. | ||
| return version == ImportNameVersion::Swift4; |
There was a problem hiding this comment.
I considered having a "Latest" version in ImportNameVersion. You could go with that, or at the very least a global in the ImportName header that is set to Swift4
There was a problem hiding this comment.
Actually, you do that further down. Any reason not to use that one?
There was a problem hiding this comment.
Whoops, forgot I added that!
lib/ClangImporter/ImportName.cpp
Outdated
| return nullptr; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Would it simplify logic to put in a return decl->getAttr<clang::SwiftNameAttr>()' before this last brace, then you can drop the check later on?
There was a problem hiding this comment.
Ah, yeah, perhaps! Good catch that they're the same condition.
jrose-apple
force-pushed
the
one-swift-two-swift-old-swift-new-swift
branch
3 times, most recently
from
93e62dc to
2da5562
Compare
|
Waiting until after Branch Day to land any of this. |
|
Also, I approve of the brach name |
jrose-apple
changed the title
|
I'll put the follow-up work in later PRs; it's good to start getting this in. @swift-ci Please test |
|
Build failed |
The compiler uses the non-active names to import unavailable declarations telling the user the correct name. Right now it's still only importing "Swift 2" and "current", but that should change. For reference, the best example of a declaration that has four names is a factory method with a custom NS_SWIFT_NAME annotation: - Its raw name is the plain Objective-C name, written as a method: 'fooByFrobnicatingBar(_:)'. - Its "Swift 2" name is the Swift-2-style translation of that to an initializer: 'init(byFrobnicatingBar:)' - Its "Swift 3" name applies the "omit needless words" transformation: 'init(frobnicating:)'. - Its "Swift 4" name uses the name specified by NS_SWIFT_NAME.
The next commit will make findSwiftNameAttr handle Swift 3 / Swift 4 API notes, so it's important that everything is consistently using it. (The other place that isn't updated yet is enum info; conceivably, the prefix for enum constants might be different based on which SwiftNameAttrs are in play.
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in both. This allows the compiler to produce sensible errors and fix-its when someone uses the "wrong" name for an API. The diagnostics certainly have room to improve, but at least the essentials are there. Note that this commit only addresses /top-level/ decls, i.e. those found by lookup into a module. We're still limited to producing all members of a nominal type up front, so that'll require a slightly different approach. Part of rdar://problem/29170671
jrose-apple
force-pushed
the
one-swift-two-swift-old-swift-new-swift
branch
from
2da5562 to
c9124d9
Compare
|
Rebased! @swift-ci Please test |
In order to ease the transition to Swift 4, we should import even renamed APIs with their Swift 3 name as well as their Swift 4 name, and use our existing rename machinery to correct the user when someone uses the wrong name (in either Swift 3 or Swift 4).
Very much a work in progress. Dependent on apple/swift-clang#53. rdar://problem/29170671