...rather than replacing particular macros with an 'annotate'
attribute and then looking for that. This isn't /really/ any
particular win except maybe ever-so-slightly faster module imports
(with one fewer attribute being added to each declaration in a
mixed-source header).
This doesn't remove the SWIFT_CLASS_EXTRA, SWIFT_PROTOCOL_EXTRA, or
SWIFT_ENUM_EXTRA macros from PrintAsObjC (note that
SWIFT_EXTENSION_EXTRA was never used). They're not exactly needed
anymore, but they're not doing any harm if someone else is using them.
ClangImporter::lookupTypeDecl allows a Clang type declaration to be
imported by Clang name instead of by Swift name. Now that we're using
Clang names in mangled names, that's exactly what we need to
reconstruct an AST type from a mangled name.
Also:
- Handle @compatibility_alias in ClangImporter::lookupTypeDecl
- Print errors when type reconstruction fails in swift-ide-test
- Add an extra test for RemoteAST
These new Clang attributes identify whether an enum is intended to
represent an option set or not, and whether the set of cases listed in
the enum declaration is exhaustive. (Swift doesn't currently have a
closed/open distinction for enums, so treat any C enum with
enum_extensibility as a proper closed Swift enum, like we do with
NS_ENUM.)
Enums with neither attribute will continue to be imported as unique
types.
rdar://problem/28476618
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.
