This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
Also lays the groundwork for rdar://problem/16513537, which is about
being able to find an enum by its original top-level name so that we
can show a diagnostic for that. I'll file a public bug about that
later.
rdar://problem/31893305
Shave off a pointer from the EffectiveClangContext, by re-arranging
some of its data. Down to 2 pointers from 3.
Inside of ImportName, factor out the does-it-have-a-value from
multiple stored Optionals so as to shave off a couple of
pointers. Present the same programming interface as before. Down to 8
pointers in size from 10, and still much further to go.
Move SwiftLookupTableReader/Writer into .cpp file, as they are
irrelevant to the rest of the importer, and this allows us to make
them more ImportName aware in the future. Pull more code out of
ClangImporter.cpp.
NFC.
...instead of picking one definition arbitrarily. This comes from the
new "lookup table" design in Swift 3---we no longer just look for any
"visible" (imported) macro definition, but instead need to know them
up front. This works fine when there's only one definition per module,
but for modules like 'OpenGL' on macOS, with mutually-exclusive
submodules 'GL' and 'GL3', the compiler was arbitrarily deciding that
all of the macros the submodules had in common belonged to 'GL'.
The new model tries to decide if it's possible for two modules to be
imported separately, and keeps both macro entries if possible, only
deduplicating equivalent definitions at the last minute (when
importing into Swift). This /still/ doesn't perfectly match the
behavior you'd get in C, where a submodule and its parent module could
theoretically have conflicting definitions and you'd be fine as long
as you only imported one of them, but hopefully (a) it's close enough,
and (b) nobody is doing that. (The Swift compiler will prefer the
definition in the parent module even if the submodule is the only one
imported.)
rdar://problem/26731529
When attempting to compile Swift 2 code (or any Swift code using the
Swift 2 names) in Swift 3, the compiler diagnostics are often entirely
useless because the names have changed radically enough that one
generally gets "no member named 'foo'" errors rather than a helpful
"'foo' was renamed to 'bar'" error. This makes for a very poor user
experience when (e.g.) trying to move Swift 2 code forward to Swift 3.
To improve the experience, when the Swift 2 and Swift 3 names of an
API differ, the Clang importer will produce a "stub" declaration that
matches the Swift 2 API. That stub will be marked with a synthesized
attribute
@available(unavailable, renamed: "the-swift-3-name")
that enables better diagnostics (e.g., "'foo' is unavailable: renamed
to 'bar') along with Fix-Its (courtesy of @jrose-apple's recent work)
that fix the Swift 2 code to compile in Swift 3.
This change addresses much of rdar://problem/25309323 (concerning QoI
of Swift 2 code compiled with a Swift 3 compiler), but some cleanup
remains.
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.
