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.
Previously, the "effective context" parameter to importFullName was
used only during the construction of Swift name lookup tables, so we
can associate each declaration with a context. Expand the role of
"effective context" so it is always a part of ImportedName and is also
used by importDecl when actually importing the enum declaration.
This is partially a cleanup, and partially staging for SE-0033, which
will require this functionality more broadly.
The two types are nearly identical, and Fixnum is only in the Swift branches of LLVM,
not in mainline LLVM.
I do want to add ++ to PointerEmbeddedInt and fix some of this ugliness, but that'll
have to go through LLVM review, so it might take a bit.
This copes with rare (and hard-to-reproduce-in-the-small) recursive
cases where importing a declaration for a name would then perform name
lookup again, and end up not finding anything the second type around.
This better matches the behavior we had before enabling the Swift name
lookup tables. Tests will be forthcoming, but this is expected to fix
a failure on Linux.
The recently-introduced module file extensions functionality in Clang
allows us to piggy-back the Swift name lookup tables in Clang's module
files. When the Swift name lookup tables are enabled, introduce such a
module file extension, and wire it into the SwiftLookupTable.
The actual contents of the extension block are simple: a single
on-disk hash table mapping base names to "full entries", which store
the context (e.g., a class, protocol, tag, or TU) and the set of
declarations.
Allow lazy resolution of declaration IDs deserialized from the
extension block to Clang declarations, to try to minimize the set of
declarations we must deserialize. Name lookup itself is only used to
dump the Swift name lookup tables and ensure we're round-tripping
properly.
The base name -> full name mapping really isn't interesting; index
based on the base name and filter by context instead. This makes the
lookup table dumper less interesting for testing purposes
(unfortunately), but test coverage will improve greatly once we can
turn on these lookup tables.
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.
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.
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.
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.
