[Clang importer] Refactor and centralize name mapping #98
Conversation
This file contains 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
When we parse a bridging header, start building a mapping from Swift names (both base names and full names) to the Clang declarations that have those names in particular Clang contexts. For now, just provide the ability to build the table (barely) and dump it out; we'll grow it's contents in time.
… logic. The Swift lookup tables are the primary client and test vehicle right now. This change adds the capability to use the swift_name attribute to rename C functions when they are imported into Swift, as well as handling the swift_private attribute more uniformly. There are a few obvious places where I've applied this API to eliminate redundancy. Expect it to broaden as the API fills out more.
We never used it for non-identifier names, and the former is somewhat ambiguous with the new importFullName.
…e. NFC The sole remaining caller to importName is for enumerators, which may have prefixes that need stripping. That refactor will come in a subsequent commit.
This is needed for member lookup via the Swift lookup tables, although the lookup part is not yet implemented. Note also that the results are currently wrong for C enumerations mapped into Swift enums or option sets. That will come shortly.
… name. This places enumerators that will become either cases of a Swift enum or options in a Swift option into the context of the C enum type for the name lookup table.
Centralize the mapping of C names to Swift names further by including enumerator prefix stripping, rather than having that as a separate path. The actual logic and code for computing the prefix is unchanged (despite moving from one file to another). This corrects the name computed for the Swift lookup tables, but is an NFC refactoring for everything else. With this, kill off importName(), because it's been entirely superseded by importFullName().
…tive-C. Start testing the construction of the Swift lookup tables in the Clang importer for Objective-C entities. Fix some obvious issues, e.g., category and extension entries should be associated with the corresponding class, and the categories/extensions shouldn't have entries in the lookup table.
…Name. Refactoring that lets the Swift lookup tables get the names right for Objective-C protocols that would conflict with another entity in the same module (or within the bridging header). It's an NFC cleanup everywhere else.
…lookup table. The getters and setters for Objective-C @Property declarations are never found by name lookup, so don't introduce them into the Swift lookup tables. Note that we exclude some of the accessibility declarations for unrelated reasons, as we do elsewhere in the importer.
…ers. We're only using this in the Swift lookup tables at the moment.
Capture the imported name, as well as some information about it, in the result of importFullName. Some of the clients need this information.
Eliminates one of the redundant places where we map Objective-C selectors over to Swift names.
This moves the hack used for UIActionSheet and UIAlertView's variadic designated initializers over into importFullName().
Yet more name-importing refactoring toward eliminating some redundant code. As a drive-by, happens to fix swift_private imports for no-parameter init methods.
This lets us kill the redundant Objective-C selector to DeclName mapping used only for methods.
…tFullName. The translation from the Objective-C NSError** convention into Swift throwing methods alters the names of methods. Move that computation into importFullName. This should be NFC refactoring for everything except the Swift name lookup tables, which will now correctly reflect this name translation.
Ensures that the Swift lookup tables get transformed name for imported CF types, including original name (which is still available). Otherwise, this is an NFC refactoring that gets the last of the naming tricks into importFullName.
…ic parameter. Fixes iOS build.
…rom Objective-C selectors. Mimic this.
DougGregor
added a commit
that referenced
this pull request
Dec 3, 2015
[Clang importer] Refactor and centralize name mapping
|
Nice! |
slavapestov
pushed a commit
to slavapestov/swift
that referenced
this pull request
Nov 27, 2018
release wrapped C objects when Swift object deinitialized
slavapestov
pushed a commit
to slavapestov/swift
that referenced
this pull request
Nov 27, 2018
release wrapped C objects when Swift object deinitialized Signed-off-by: Daniel A. Steffen <[email protected]>
maldahleh
pushed a commit
to maldahleh/swift
that referenced
this pull request
Oct 26, 2020
[classifier] Provide a more efficient classification mechanism
freak4pc
pushed a commit
to freak4pc/swift
that referenced
this pull request
Sep 28, 2022
Add Swift 4.0 compatibility commit for SwiftLint
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.
The Clang importer performs a number of translations from the names of (Objective-)C APIs into their Swift counterparts, but the logic was scattered across various places---Objective-C mapping in one place, factory methods being imported as initializers in another, enums in a third place, CF types elsewhere. Refactor and centralize the logic that performs name mapping into a single function, ClangImporter::Implementation::importFullName. This part is almost entirely NFC, which I've verified by comparing the imported APIs for all of Cocoa[Touch] before/after. The only difference is that we stop generating a handful of weird typealiases when dealing with typedefs of CF types, e.g.,
Also, optionally start building a table that maps from the Swift names of entities back to the (Objective-)C entities that generate those names, using the new importFullName(). Do this as a result of parsing the (Objective-)C, without importing anything. At present, this is being used as a debugging aid for the refactoring in this pull request. In the future, we'll continue building out this table so we can start using it for name lookup rather than falling back to Clang's name lookup.