This introduces support for swift_newtype(struct) attribute (also
known as swift_wrapper). The Clang importer will create a brand new
struct corresponding to the annotated typedefs, which has a backing
raw value. Globals of that type are imported as static members on the
struct.
Additionally, this interacts seamlessly with prior import-as-member
work, meaning that the newly created type can be imported onto. Tests
included.
Introduces CoreGraphics.apinotes, in which we enable the
import-as-member inference system. Additionally, include some explicit
SwiftNames, for when inference doesn't produce the right result, and
to aid compatibility with the overlays.
Refactors many of the trivial overlays out, shrinking the
CoreGraphics.swift overlay by over half. Updates in-tree test
cases. The names we currently have will be highly in flux for a while,
and are likely to change frequently over the near term.
There are a few remaining known bugs that are worked around by
apinotes entries.
It's possible for swift_name to make a global declaration into a
member of another entity that has not been seen yet. In such cases,
delay resolution until the end of the translation unit (module). Fixes
the rest of rdar://problem/25502497.
ObjC containers and categories are valid effective Clang decl
contexts, but do not have a canonical declaration. Permit them
alongside translation units.
When an Objective-C class type is annotated with the swift_bridge
value type, bridge it to the named type. Use API notes on Foundation
rather than special cases.
For Objective-C classes where bridging was baked into the Clang
importer (NSString, NSArray, NSDictionary, NSSet), add API notes to
put the appropriate swift_bridge attribute on these Objective-C
classes.
Note: requires Clang update.
Read through attributed types when determing effective Clang decl
context, use lower level CF type information, and const-ify
EffectiveClangContext.
This puts an end to known disappearing imported members.
When printing the interface for a (sub)module, make sure that we only
print those extensions that were created to hold that submodule's
globals that were imported as members.
Whenever we add an entry that corresponds to a global Clang entity
that will be imported as a member, where that member structure isn't
inherently encoded in Clang, separately record it as being a member of
the context in a separate table. Verify that we're getting the entries
we expect in this table.
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.
We're going to delay NS prefix stripping for a bit. Change the API
dump script accordingly, and bump the Swift name lookup table format
version number so this doesn't break everyone who has already run
swift-api-dump.py.
We were verifying the Swift full version information from the module
file extension metadata for the Swift name lookup tables, but not
actually putting it in the hash, which meant that having an older
module cache around would cause spurious failures when Swift name
lookup tables were enabled. Instead, use just the major/minor version
numbers of the lookup tables. When the lookup table format or contents
of the lookup table change, we'll bump the version number.
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.
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.
