[swift-dev] Clang importer: enabling Swift name lookup tables

Douglas Gregor dgregor at apple.com
Sun Dec 20 16:23:26 CST 2015


Hi all,

I’ve been working on the Clang importer’s Swift name lookup tables for the last few weeks, and they’re now at a point where I’d like to turn them on by default. Essentially, this replaces the ad hoc mechanism we are currently using in the Clang importer to find entities by name with a mechanism that caches, within each Clang module file, a mapping from Swift names back to the Clang declarations that produce a Swift declaration with that name. There are a number of benefits to this approach:

* The mapping of names from (Objective-)C to Swift is centralized (in ClangImporter’s importFullName) and doesn’t need to be “reversed” in name lookup in an ad hoc way.
* We’ll eventually deserialize less of the Clang module to find what we’re looking for, because we can search based on the Swift name we need rather than searching (see below for details), which should improve compile-time performance
* We’ll eventually be able to more easily respect (sub-)module boundaries for Clang

There are a several outstanding bugs that should be fixed by this change, including:

* The (Objective-)C swift_name attribute currently can’t be applied to global names without breaking the Clang importer.
* Objective-C properties whose names differ from the names of their getter (e.g., "@property(getter=isFoo) BOOL foo;”) can’t be found by name lookup on any AnyObject.
* When enabling the Swift 3 renaming (-enable-omit-needless-words), name lookup on an AnyObject is completely broken.

At the moment, I’ll only be enabling the Swift name lookup for the first two of three name lookup mechanisms we use:

* Module-scope lookup, which finds global names (e.g., NSDate).
* AnyObject lookup, which finds Objective-C methods/properties/subscripts on a value of type AnyObject (or metatype thereof)
* [Not yet ready] Objective-C class/protocol member lookup. This is lookup within the scope of a class or protocol, which currently relies on us deserializing everything in a class, its extensions, its adopted protocols, and applying that recursively through all superclasses. This is where we’ll expect the big compile-time win, because we should be able to jump directly to the appropriate declarations.

I’ll flip the switch tomorrow sometime; if you see any regressions that look related to name lookup, please tell me!

	- Doug



More information about the swift-dev mailing list