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.
Clean up our handling of the removal of the "NS" prefix from
Foundation-defined entities in a few ways:
* If the "NS" is followed by a "_", strip that too
* Make sure that the result is still an identifier ("NS123" shouldn't
become "123"!)
* Don't lowercase ALL_CAPS_NAMES
CF types are generally imported twice, once with the "Ref" and once
without the "Ref", unless the non-"Ref" version would conflict with
some other declaration (e.g., an Objective-C class of the same name).
The logic to create both versions was a bit convoluted, and tended to
return the "Ref" version as the primary declaration, which conflicts
with our general inclination to use the non-"Ref" version. Now we create
the non-"Ref" version directly and then create the aliased "Ref" version
as an alternate declaration. The "Ref" version is a typealias of the
non-"Ref" version, and the "Ref" version is never used anywhere else
in the AST.
Also, improve the conflict resolution for cases where the only
conflicting declaration is an opaque tag used to declare the CF type
itself, e.g.,
typedef struct CGImage *CGImageRef;
These cases used to be considered conflicts, but they are benign
because the underlying struct will never actually be imported. Make
them not conflicts, so we get the preferred name "CGImage" rather than
"CGImageRef".
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
As part of the improved import of Objective-C APIs into Swift, strip
the "NS" prefix from entities defined in the Foundation
framework. Addresses rdar://problem/24050011, which is part of
SE-0005. Naturally, this is hidden behind -enable-omit-needless-words.
The Clang importer implementation held on to a Clang instance, which
held a list of module file extensions, which included the Clang
importer implementation... break the cycle by separating out the
module file extension from the Clang importer. Fixes SR-562 /
rdar://problem/24225173.
