The swift_name string format now supports "getter:" and "setter:"
prefixes to indicate that a function is the getter or setter of a
Swift-synthesized property. Start parsing these DeclNames and make
sure they're reflected in the Swift name lookup tables.
[Clang update required]
A swift_name attribute on a global declaration can specify a dotted
name (e.g., SomeStruct.member) to map that global into a member of the
(Swift-)named type. Handle this mapping in DeclName parsing, plumb it
through importFullName, and cope with it in the Swift name lookup
tables (tested via the dump) and importing into a Swift DeclContext
(as-yet-untested). Part of SE-0033.
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.
The sole remaining caller to importName is for enumerators, which may
have prefixes that need stripping. That refactor will come in a
subsequent commit.
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.
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.
