More specifically, don't try to emit a definition for them. Just fall
through to what we do for forward-declarations...which also needed some
fixing, to make sure we don't use a Swift typealias as its underlying
type but never import the underlying type.
https://bugs.swift.org/browse/SR-2352
When bridging values via the ObjectiveCBridgeable protocol,
SILGen has to look up conformances directly, behind the
type checker's back.
To make sure the ObjectiveCBridgeable conformance is forced,
Sema calls useObjectiveCBridgeableConformances() in the right
places.
However, another conformance we may also need when bridging
is the Hashable conformance for a Set or Dictionary's key type.
Make sure we force these too, because otherwise when bridging
a nil literal nothing needs them in Sema.
Fixes <rdar://problem/27470505>.
Attempting to throw an error code value, e.g.,
throw CocoaError.fileNoSuchFileError
is now ill-formed, although it was well-formed prior to the
introduction of NSError bridging (SE-0112). Provide a specialized
diagnostic with a Fix-It to add the appropriate parentheses:
throw CocoaError(.fileNoSuchFileError)
Fixes rdar://problem/27543121.
* [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.
When a parameter has distinct "nil" and "empty" values, "nil"
generally represents the default settings, while "empty" is
explicitly cleared.
rdar://problem/27196867
Introduce bridging of NSError to ErrorProtocol, so an Objective-C API
expressed via an "NSError *" will be imported using ErrorProtocol in
the Swift. For example, the Objective-C method:
- (void)handleError:(NSError *)error userInteractionPermitted:(BOOL)userInteractionPermitted;
will now be imported as:
func handleError(_ error: ErrorProtocol, userInteractionPermitted: Bool)
This is bullet (3) under the proposed solution of SE-0112. Note that
we made one semantic change here: instead of removing the conformance
of NSError to ErrorProtocol, which caused numerous problems both
theoretical and actual because the model expects that an NSError
conforms to ErrorProtocol without requiring wrapping, we instead limit
the ErrorProtocol -> NSError conversion that would be implied by
bridging. This is defensible in the short term because it also
eliminates the implicit conversion, and aligns with SE-0072, which
eliminates implicit bridging conversions altogether.
When we have an argument expr of type Any that's being emitted as a bridged ObjC object parameter, look through any ErasureExprs and directly bridge the concrete value. This saves us emitting an intermediate 'Any' value in the common case where a value of known concrete type is passed in from Swift.
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>.
Now that ObjC types can be generic, we need to satisfy the type system by plumbing pseudogeneric parameters through func-to-block invocation thunks. Fixes rdar://problem/26524763.
This shows that the owner of the option set has thought about the
zero case, and wants it to be available in Swift, rather than disabling
it with the default "use [] to construct an empty option set" message.
rdar://problem/26290766
We were failing to bridge Array<T> parameters in the signatures of Objective-C generics when their NSArray<T> * type in ObjC depended on generic parameters. This partially fixes rdar://problem/26371959, though IRGen still needs a fix to get us all the way through (which @rjmccall is working on).
(@DougGregor did all the work here, I'm just testing and committing.)
We were failing to create an unavailable TypeAlias for the old name
in the case the renamed type was generic, leading to poor diagnostics.
Also, Sema resolves generic TypeAliases very early, while building
a Type from a TypeRepr -- this means the unavailable/deprecated
check runs too late to catch generic TypeAlises.
Add a hack where we preserve a reference to the original TypeAliasDecl
by way of constructing a SubstitutedType which desugars to the
replacement type, rather than resolving the replacement type
directly, so that the availability check can pick it up.
A better fix for this would be to introduce a BoundGenericAliasType
sugared type, but that's a bigger change that can come later.
Fixes <rdar://problem/26206263>.
The fix for methods to lower the dynamic method type from the substituted AST type of the expression also needed to be applied to the optional chaining, subscript, and property paths.
This also exposed a problem in the Clang importer, where imported subscript accessors would get the unbound generic context type as their Self parameter type instead of the type with the correct generic parameters. Fix this by renaming the all-too-convenient ParamDecl::createSelf factory to `createUnboundSelf`, and introduce a new `createSelf` that uses the bound generic type.
Fixes rdar://problem/26447758.
That is, import something like 'CGColorCreateGenericGray' as
"CGColor.init(gray:alpha:)" rather than "CGColorRef.init(gray:alpha:)".
Since we print the type name in diagnostic text and in fix-its, it's
important to use the name that Swift sources use.
Finishes rdar://problem/26347297.
The unavailable-in-current-Swift declarations introduced by the Clang
importer to help with migrating Swift 2.x code to Swift 3's naming
cause problems with unqualified name lookup when they shadow, e.g.,
types. The biggest problem in practice is with "URL", which is a
common Cocoa property name (in Swift 2) that becomes "url" in Swift 3,
but the old name conflicts with the Foundation value type "URL".
Fixes <rdar://problem/26236989>.
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.
This is a squash of the following commits:
* [SE-0054] Import function pointer arg, return types, typedefs as optional
IUOs are only allowed on function decl arguments and return types, so
don't import typedefs or function pointer args or return types as IUO.
* [SE-0054] Only allow IUOs in function arg and result type.
When validating a TypeRepr, raise a diagnostic if an IUO is found
anywhere other thn the top level or as a function parameter or return
tpye.
* [SE-0054] Disable inference of IUOs by default
When considering a constraint of the form '$T1 is convertible to T!',
generate potential bindings 'T' and 'T?' for $T1, but not 'T!'. This
prevents variables without explicit type information from ending up with
IUO type. It also prevents implicit instantiation of functions and types
with IUO type arguments.
* [SE-0054] Remove the -disable-infer-iuos flag.
* Add nonnull annotations to ObjectiveCTests.h in benchmark suite.
If NSInteger and NSUInteger typedefs are available in the current Clang context, use them when mapping Swift's Int and UInt to Clang types. This gives us consistent method and property type encodings for @objc methods with Clang, fixing rdar://problem/17506068.
Though the generic type information isn't present, it isn't necessary if we're just invoking other operations from Objective-C. This should allow an extension to use the generic class's own API to some degree, as it would if defined on the nongeneric form.
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
If a particular typealias is unavailable in Swift, don't form types
that reference that typealias. Use the underlying type instead.
Fixes rdar://problem/25450337.
When importing members of an NS_OPTIONS (aka an option set), mark imported
members that have a value of 0 with an unavailable error. This produces an
experience like this:
x = NSRuncingOptions.none // expected-error {{'none' is unavailable: use [] to construct an empty option set}}
This is important to do, because option set members with a value of zero
do not act like members of the option set. For example, they always fail a
"contains" check.
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
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.
