More specifically, don't include declarations of methods and properties
in the list of "all imported Objective-C members" if said method or
property is in a generated header. (We actually key off of whether the
enclosing class, protocol, or category is marked as coming from Swift,
but since users aren't supposed to modify generated headers themselves
it's much the same thing.)
This previously caused a crash because we tried to import a Clang member
onto a Swift decl in order to provide the particular member on AnyObject.
rdar://problem/25955831 and probably also rdar://problem/25828987, which
deals with the fix-it to migrate to #selector. (We do an AnyObject-like
lookup to find out which class likely implements the specified selector.)
Leftover bits of SE-0055. Now that pointer nullability is reflected
in the type system, we can properly import throwing methods with
non-object pointer return types.
Note that Swift still won't let you declare them. That's coming next.
We now specially import global decls who we identify as fitting the
notification pattern: extern NSStrings whose name ends in
"Notification". When we see them, we import them as a member of
NSNotificationName and, if NSNotificationName is swift_newtype-ed, we
use that new type.
Test cases included.
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.
On the Raspberry Pi 2 when trying to import Glibc, without this patch, it will attempt to
find the module map at "/usr/lib/swift/linux/armv7l/glibc.modulemap" and
fail to do so.
With this patch it will attempt to find the module map at
"/usr/lib/swift/linux/armv7/glibc.modulemap" where it will succeed in
finding the module map.
Similar behavior currently happens in the Driver and Frontend. To DRY up
this behavior it has been extracted to the Swift platform.
It should have the same form as the argument to NS_SWIFT_NAME
in Objective-C, except that it permits operators and (currently)
disallows instance members and properties. We do get to share the
same parsing code, at least.
This actually caught an error in the Foundation overlay!
Groundwork for SR-1008.
Rather than do whole-word common-word stripping, we only strip common
prefixes. This is not as powerful as what was originally intended, but
much less magical in the mapping into Swift.
Test case adjusted, and common utility functions exposed.
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.
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.
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.
