Sema was dutifully tracking conformances that were "used" as part of
type checking, so it could make sure that those conformances got
completed for SILGen to use. However, this information never actually
made it to SILGen, which included its own (more conservative, not
broad enough) heuristics for finding "used" conformances. Teach Sema
to record conformances within the appropriate source file, and have
SILGen reference the conformances when it emits SIL for the source
file.
Special case logic for CF types, which may be coming in as
unmanaged. In this case, we will use audit information if present to
import with the new type, otherwise we have to fall back to
Unmanaged<CF...>.
We still import global variables that must be unmanaged onto the new
type, though they keep their unmanaged types. This helps to
consolidate the definitions, as well as make future migration easier
if they get audited.
Test cases included.
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.
For swift_newtype structs that we create, we sometimes need to provide
a bridged type interface. In these cases, we use the original
non-bridged type as an underlying stored value, and create a computed
rawValue of bridged type. We similarly create an init() taking the
bridged type, and cast it appropriately to/from storage.
Tests updated.
The Clang importer implicitly synthesizes @discardableResult for
nearly all imported functions. Printing this attribute in the
generated interface leads to a lot of noise. Mark it as implicit so we
don't print it.
This is a temporary solution that implements swift_newtype(enum) as
though it were written swift_newtype(struct). This is to work around
to the fact that a String-backed enum does not actually have a String
stored, and a struct is closer to reflecting that storage
properly. Struct provides most of the functionality and appearance for
now, though it does not allow for switching over the values.
Full support for swift_newtype(enum) as a Swift enum is forthcoming.
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.
While inferring get/set, we paired them up even when one of them was
available through a custom objc header (e.g. a private
header). Instead, fail to pair them up. Test case added.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
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.
Some of the callers to importDeclContextOf could and should have
passed an effective context, but didn't, so (e.g.) an enum defined in
C couldn't be mapped to a nested type in Swift. Eliminate the
single-argument importDeclContextOf honeypot so we remember to pass
down the effective Clang context. Fixes rdar://problem/25502497.
For the most part this was just "check isInstanceProperty"; the one feature not yet implemented
is the emission of ObjC metadata for class properties.
rdar://problem/16830785
In the Clang importer, and only in submodules, the first protocol
typedef with NSObject that we try to import results in a hidden lookup
result. So, allow hidden lookups, which is benign and failure is
actually an issue of a malformed header. Gracefully handles failure.
Test case included that will reproduce the issue if AllowHidden is
disabled.
There's an odd, and unknown bug in the Clang Importer where we seem to
fail a Clang lookup of NSObject the very first time we try. While I'm
still diagnosing this, un-block SILGen work.
Introduce abstraction patterns for curried C-functions-as-methods for type lowering, and plumb the "foreign self parameter index" through call emission so that we emit the "self" parameter in the right position. This gets us handling C functions imported as methods with explicit swift_name attributes in simple, fully-applied cases. There's still more work to be done for properties, partial applications, and initializers introduced by extensions.
Pass through the original Type in addition to the TypeDecl so that we
can distinguish DynamicSelfType with underlying ClassType from just any
old ClassType.
rdar://problem/25158493
