Conditional and forced downcasts enter a constraint that almost
always succeeds; only when applying the solution do we evaluate
the feasability of the cast and determine if it always succeeds,
always fails, or conditionally succeeds. This changes how the
resulting AST is represented and can also emit diagnostics.
If the conditional cast is at this stage determined to always
succeed, we treat it as an unconditional cast, going through
ExprRewriter::coerceToType() to build the AST for the coercion.
However conditional cast constraints don't enter the same
restrictions into the solution as unconditional casts do, so
coerceToType() would fall over if casting a Swift type to a CF
type by first bridging the Swift type to Objective-C.
Get around this by checking for this case explicitly when
lowering a CoerceExpr.
It feels like there's a more fundamental issue here with how
casts are modeled in the constraint solver, but I'm not going
to try understanding that now.
Fixes <rdar://problem/32227571>.
(and similar for flag_enum)
This commit prepares the importer for a world in which NS_ENUM and
NS_OPTIONS have adopted the new Clang attributes 'enum_extensibility'
and 'flag_enum', but API notes are used to reverse the effect. Without
this there would be no transition path for adopting the standard Cocoa
macros, which have applied unconditionally up to now.
rdar://problem/18744821
These new Clang attributes identify whether an enum is intended to
represent an option set or not, and whether the set of cases listed in
the enum declaration is exhaustive. (Swift doesn't currently have a
closed/open distinction for enums, so treat any C enum with
enum_extensibility as a proper closed Swift enum, like we do with
NS_ENUM.)
Enums with neither attribute will continue to be imported as unique
types.
rdar://problem/28476618
In Swift 3, an Objective-C type like SomeClass <SomeProtocol> is
imported as SomeClass. The protocol qualification is erased unless
the class bound is 'id' or 'Class'.
Importing such types as class-constrained existentials is a source
breaking change, so the new behavior is only enabled in Swift 4
mode.
Furthermore as a transitional step the staging flag
-enable-experimental-subclass-existentials has to be passed in
also. The flag will soon be removed.
This writeback scope's writeback is handled by the ArgumentScope for argument
emission. Since the scope will be destroyed after argument scope, we get
mismatched scope depths.
rdar://31313534
Most of the time the name importer does a good job deciding whether to
import a particular method as throwing or not. However, when a method
is an override, it skips all that work and assumes the decisions made
for the superclass method apply here as well---which makes sense,
since you're going to get the subclass implementation if you call the
superclass's entry point. This can really throw things off if the
types /don't/ match up, though. Handle the one case where this is
legal according to the rules of Objective-C, and make sure we don't
import methods in the other cases.
rdar://problem/30705461
This was causing the importer to complain about not being able to map
'dispatch_sync' to 'DispatchQueue.sync(self:execute:)', but only when
building the PCM for our mock Dispatch. That meant that it depended on
the test order whether we'd see issues---if the first test to build
the module didn't check for warnings in other files, it would slip by.
This was usually blocks_parse.swift.
rdar://problem/30475805
Most of the time, "generics" means "cannot be exposed to Objective-C"
and certainly "cannot be exposed in the generated header", but there
is one exception: imported Objective-C parameterized types, and their
extensions. We were previously dropping this on the floor and printing
`Foo</* BarType */>` in the generated header, which is nonsense.
https://bugs.swift.org/browse/SR-3480
Specifically, a forward-declaration of one struct inside another.
This isn't a field, so it doesn't affect whether or not the struct
has addressable storage, nor whether it should get a memberwise
initializer.
This change matches Swift 3.0 behavior. I'm not exactly sure why,
because as far as I can tell Swift 3.0 should have also been leaving
out the memberwise initializer. But it doesn't appear to have been
doing so, and including it is more correct anyway.
rdar://problem/30449400
Or rather, when the name importer decides that the name it /would/
have should start with a number, and gives up. We should probably
fix that separately, but meanwhile don't crash.
> Roses are red
> Prefix-stripping can create an invalid remainder
> assert(!member->NextDecl &&
> "Already added to a container")
rdar://problem/30401506
...and avoid making aliases from one unavailable declaration to another.
If it's unavailable, we can just import it as a normal case and not
worry about it. This fixes an issue where Sema would try to diagnose
the body of an "alias" for referring to unavailable declarations.
(Background: enum cases in Swift have to have unique values, so we
import any duplicate values as static properties. Pattern matching
logic has a hack to recognize these particular static properties as
being "case-like".)
This commit also sinks enum element uniqueness checking into importing
the enum, instead of keeping a global map we never consult again. This
should save a small bit of memory.
rdar://problem/30025723
integer constants, and to always look through macro definitions for them.
Also, logical comparisons now return a Boolean.
New operations: +, -, *, /, ^, >>, ==, >, >=, <, <=
Previously, for an Objective-C class method declaration that could be
imported as init, we were making 4 decls:
1) The Swift 2 init
2) The Swift 2 class method decl (suppressing init formation)
3) The Swift 3 init (omitting needless words)
4) The Swift 3 class method decl (suppressing init formation and
omitting needless words)
Decls 1), 2), and 4) exist for diagnostics and redirect the user at
3). But, 4) does not correspond to any actual Swift version name and
producing it correctly would require the user to understand how
omit-needless-words and other importer magic operates. It provides
very limited value and more importantly gets in the way of future
Clang importer refactoring. We’d like to turn Decl importing into
something that is simpler and language-version parameterized, but
there is no real Swift version to correspond to decl 4).
Therefore we will be making the following decls:
1) The "raw" decl, the name as it would appear to the user if they
copy-pasted Objective-C code
2) The name as it appeared in Swift 2 (which could be an init)
3) The name as it appeared in Swift 3 (which could be an init and omit
needless words)
This aligns with the language versions we want to import as in the
future: raw, swift2, swift3, …, and current.
Note that swift-ide-test prunes decls that are unavailable in the
current Swift version, so the Swift 2 non-init decls are not printed
out, though they are still present. Tests were updated and expanded to
ensure this was still the case.
Most people don't even think of va_list as a pointer type, so they
won't bother to put nullability on it. Conversely, on some platforms
va_list /isn't/ a pointer type (or an array that decays to a pointer
type in parameter positions), so putting nullability on a va_list
would be non-portable.
If nullability isn't explicitly specified for a va_list, or even if
it's explicitly marked _Null_unspecified for some reason, treat it as
non-optional in Swift. Anyone who /really/ needs to (non-portably)
pass NULL to a va_list parameter can do so via a C trampoline
function.
This change is potentially source-breaking, since someone could be
passing NULL to a va_list today. However, this is incredibly unlikely,
and even less likely to do something useful.
More fallout from rdar://problem/25846421 (supporting nullability on
array parameters).
If the keyword 'static' also appears within the '[' and ']' of the
array type derivation, then for each call to the function, the
value of the corresponding actual argument shall provide access to
the first element of an array with at least as many elements as
specified by the size expression. (C11 6.7.6.3p7)
Limit this change to Swift 4 so as not to break existing code, though
use of 'static' in this way is rare to begin with and passing nil
would probably be an error anyway.
Small part of rdar://problem/25846421.
Upstream cfe change r284797 adds explicit handling for modules
named Darwin, and requires that it not depend on modules which
it does not parent. Because ctypes is a peer module of Darwin,
this means that Darwin must no longer depend on ctypes.
This can be avoided by duplicating some integral definitions
in MacTypes.h, and by adding extra imports to a few tests.
For every struct type for which the frameworks provides an NSValue category for boxing and unboxing values of that type, provide an _ObjectiveCBridgeable conformance in the Swift overlay that bridges that struct to NSValue, allowing the structs to be used naturally with id-as-Any APIs and Cocoa container classes. This is mostly a matter of gyb-ing out boilerplate using `NSValue.init(bytes:objCType:)` to construct the instance, `NSValue.objCType` to check its type when casting, and `NSValue.getValue(_:)` to extract the unboxed value, though there are a number of special snowflake cases that need special accommodation:
- To maintain proper layering, CoreGraphics structs need to be bridged in the Foundation overlay.
- AVFoundation provides the NSValue boxing categories for structs owned by CoreMedia, but it does so using its own internal subclasses of NSValue, and these subclasses do not interop properly with the standard `NSValue` subclasses instantiated by Foundation. To do the right thing, we therefore have to let AVFoundation provide the bridging implementation for the CoreMedia types, and we have to use its category methods to do so.
- SceneKit provides NSValue categories to box and unbox SCNVector3, SCNVector4, and SCNMatrix4; however, the methods it provides do so in an unusual way. SCNVector3 and SCNVector4 are packaged into `CGRect`s and then the CGRect is boxed using `valueWithCGRect:`. SCNMatrix4 is copied into a CATransform3D, which is then boxed using `valueWithCATransform3D:` from CoreAnimation. To be consistent with what SceneKit does, use its category methods for these types as well, and when casting, check the type against the type encoding SceneKit uses rather than the type encoding of the expected type.
Actually bridging ObjCBool to Bool is overkill for this, but moreover
it caused problems for non-boolean types that took this code
path. Just go back to the previous logic of unwrapping multiple levels
of struct; this way we can also handle wrappers around integer types
(if we ever have any).
rdar://problem/27985744
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.
