[WIP] Testing more multi name import stuff #7749
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
This shouldn't have any effect since we've never customized how parameter names are imported (body names, not argument labels), but it removes special cases.
This doesn't actually have any effect yet, but if we start importing both Swift 3 and Swift 4 versions of protocol requirements and the non-active one is unavailable, we might mistakenly mark the protocol un-implementable even when the requirements that are needed are all there. (Hopefully we would never make a protocol /less/ available in a newer release, of course.) The test case is designed to catch that.
When a C declaration is marked unavailable with a replacement, we look for the replacement to see how it would be imported into Swift. Make sure we do that with respect to the active language version.
Unlike values, we can't import multiple copies of types under different names and get good results. Instead, we make a typealias that points back to the original type. Make sure this typealias is flagged with whatever version is appropriate, rather than always using "Swift 2".
The compiler itself no longer uses this API but the debugger does, in order to pretty-print option sets. The normal way to test this would be to add an LLDB-side test that uses a framework with versioned API notes. Unfortunately I can't think of a straightforward way to test it Swift-side.
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extra patches on top of #6720 that continue down this route. I'll split this out into proper PRs later, but I want to see if testing catches any issues.