This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
commit needed to be reverted because of an issue in which install
targets were added to OS X builds that did not target Linux. This
addresses that issue by guarding all the Linux-only CMake logic with a
check for the SDK being built.
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.
Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:
1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.
https://github.com/apple/swift/pull/1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.
This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).
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.
Print module functionality hooked up to import global functions a
methods, if dictated by the swift_name attribute. Test case included.
No SILGen support yet.
Wire up the extensions created when importing globals-as-members via
the same mechanisms we use for Objective-C categories, e.g.,
implementing loadAllExtensions() to find the extensions and lazily
loading their members via the member loader. Addresses most of my
comments on the way extensions were wired in.
Extend our testing for importing globals as members to two different
submodules, so we can see the separation of extensions.
As part of this, fold getOrCreateExtension into importDeclContextOf.
Specially identify and import-as-init. Module printing works, but not
SILGen.
This will break any SILGen tests over a file that imports a module
with an import-as-init name, as newly imported inits are not hooked up
correctly.
When importing as a member, we want a single unique extension
declaration per type per Clang submodule. This adds the mapping,
switches import-as-member VarDecl importing to use it, and forces the
created extensions to show up.
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.
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.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
(including both classes and categories, and also @protocol declarations)
This is a hack in that we use two different mechanisms for importing
bridging header decls now: the manual output of ParseTopLevelDecl, and
the callbacks of a clang::ASTConsumer. We should probably unify these,
but that's a bigger change that isn't as obviously safe.
Also note that we probably aren't getting this right for things included
with -include, which we already don't have a good model for.
This adds test cases for both the module and bridging header cases,
although the former worked correctly already.
rdar://problem/24806068
Introduce DarwinPlatformKind, which would allow us to switch on darwin
platforms instead of copying and pasting the brittle logic in several places.
Use the helper method to simplify ClangImporter.
Rather than managing API notes directly in the Clang importer, tell
Clang where to find the API notes files and let it map them directly
to attributes. Then, use the existing attribute-mapping
mechanisms---with minor extensions for cases where Clang previously
didn't map some Swift-specific API notes---to get at that information.
There is a minor regression where we can no longer apply API notes to
declarations that don't have a specific Clang declaration. The
specific example (NSError's inherited init()) comes from
rdar://problem/21042412; we've regressed here, but the correct fix is
(and has always been) on the Objective-C side
(rdar://problem/19977891).
Finishes rdar://problem/24447420.
When we transform an Objective-C method or property name, we take into
account the parameter types, result type, and type of the enclosing
context. Doing so means that one can get different Swift names for a
particular method (or property) and one that overrides it, which leads
to dangerous inconsistencies in the Swift names. Address this
limitation by using the original declaration's name (i.e., one that
does not override any other).
It is possible that there is more than one "original declaration",
when the same method/property name comes from different
protocols. When this is the case, check for consistency and complain
if there are inconsistencies.
Amusingly, this changes exactly one method in Cocoa
(UINavigationController's showViewController:sender:), with no conflicts
detected. Fixes rdar://problem/24558337.
Introduces new class, EnumInfo, just for the implementation of the
ClangImporter to encapsulate various computed information about the
enum we're importing.
This helps refactor some functionality, aids clarity, and also
prevents us from repeating calculations multiple times, as we were
doing with classifyEnum's macro-expansion tracking. Provides a base
where we can add more heavy lifting in classifyEnum in the future.
