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.
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.
