Refactors out some definitions and types from the
ClangImporter::Implementation into a new component ImportName. Future
work will include more separation and finally some redesigning of name
determination components.
We need to enable blocks support in the ClangImporter on
non-Darwin platforms for libdispatch (and transitively foundation).
The simplest way to do this is to just enable blocks unconditionally.
Also enable two Linux tests that are no longer XFAILS
...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
* [ClangImporter] Remove importer-based NS stripping.
As Tony puts it, in the end we wound up with more Foundation
declarations imported as members or keeping "NS" than those that
dropped it, and any further decisions will be made on a case-by-case
basis. Move all of the existing cases of prefix-stripping into
Foundation's API notes and drop the logic from the compiler.
Tested by dumping the generated interface for Foundation and its
submodules for both macOS and the iOS simulator, and comparing the
results. A few cases did slip through here because of the interaction
between "SwiftName" and "Availability: nonswift".
The next commit will re-add "NS" to some stragglers that we missed.
rdar://problem/26880017
* APINotes: Add "NS" back to a few types.
NSKeyedUnarchiverDelegate
NSKeyedArchiverDelegate
NSTextCheckingTypes
NSBinarySearchingOptions
NSEnumerationOptions
NSSortOptions
More rdar://problem/26880017
* Remove now-redundant SwiftNames from API notes.
No change observed in the generated interface of Foundation and its
submodules.
Finishes rdar://problem/26880017.
A given Objective-C error enum, which is effectively an NS_ENUM that
specifies its corresponding error domain, will now be mapped to an
ErrorProtocol-conforming struct that wraps an NSError, much like
NSCocoaError does. The actual enum is mapped to a nested "Code"
enum. For example, CoreLocation's CLError becomes:
struct CLError : ErrorProtocol {
let _nsError: NSError
// ...
@objc enum Code : Int {
case ...
}
}
This implements bullet (2) in the proposed solution of SE-0112, so
that Cocoa error types are mapped into structures that maintain the
underlying NSError to allow more information to be extracted from it.
We map clang::AvailabilityAttr::getReplacement() to
swift::AvailableAttr::Rename, transforming the replacement
name using by looking up the named Clang replacement, and
importing its name.
Fixes <rdar://problem/26301742>.
Due to swift_name and swift_newtype, we are frequently importing onto
different contexts. This was confusing the fixit logic for unavailable
swift2 names, as we were trying to use Clang names when the Swift name
might be totally different (and even a nested type). This change has a
two-fold effect:
1) Globals who are imported onto swift_newtype-ed typedefs should be
considered ImportAsMember.
2) When printing out the name of an ImportAsMember Swift 3 decl, we
need to print out a fully qualified context, which also uses the
Swift names, not the Clang names.
More generally, an unavailable initializer shouldn't stomp on an
available initializer, because it's possible that (for example) a
designated initializer will be unavailable but a factory initializer
will be available, so one still construct objects of that type.
Fixes rdar://problem/26238032.
Otherwise, the lookup table for "CGColor" has two entries, because of
this:
typedef struct CGColor *CGColorRef;
and that interferes with our ability to import things as members of
"CGColor" (as opposed to "CGColorRef"), which affects the fix-its we
generate when you try to use the non-member form.
This isn't necessarily the best long-term solution (as noted in the
FIXME) but it is expedient and won't break any current users.
More rdar://problem/26347297
Previously we imported a Core Foundation type "CCFooRef" as "CCFoo",
but also provided a typealias "CCFooRef". In Swift 3, we decided to
mark "CCFooRef" unavailable to force developers to consistently use
"CCFoo". Now that we have infrastructure to mark /all/ renamed
declarations as unavailable, just use that to track the renaming,
i.e. pretend that "CCFooRef" was the "Swift 2" name for the type.
This doesn't change the conflict resolution behavior: if there's
another name "CCFoo" in the same module, the CF type will be
imported as just "CCFooRef".
Groundwork cleanup for rdar://problem/26347297, which notes that our
import-as-member fix-its use the "Ref" names rather than the short
names.
Previously, we had hacks in place to eagerly emit everything in
the global ExternalDefinitions list. These can now be removed,
at least at the IRGen layer.
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.
