While the compiler can bridge C block types to Swift function types,
the Swift runtime cannot. Don't bridge block types to Swift function
types in Objective-C generic arguments, so
NSArray<some-block-type>
will get imported as
[@convention(block) (...) -> Whatever]
rather than
[(...) -> Whatever]
Fixes rdar://problem/40879067 in a fairly narrow way; the Clang
importer's approach to adjusting types based on context needs a
cleanup, but this is the safe, localized fix suitable for 4.2.
We were failing to bind the alternatives for an IUO @optional
requirement because we forgot to set the appropriate type variable option.
Fixes: rdar://problem/40868990
When trying to figure out errors from an import failure, the nullability
completeness warnings would clutter the output making it difficult to
identify the errors. Sprinkle the declaarations with
`_Null_unspecified` to maintain the current nullability semantics and
silence the warnings. NFC.
When the swift_bridged_typedef attribute is present on a typedef,
import the underlying type as bridged (e.g., String) rather than as
its unbridged type (e.g., NSString).
Fixes rdar://problem/39497900.
Avoid a temporary file and executing FileCheck multiple types and prefer
multiple check prefixes and streaming. Additionally, enable some of
previously XFAIL'ed tests on Linux as well as tests that were marked as
requiring Objective-C interop.
We want to treat arguments to ObjC override and protocol conformance thunks like "call results", since they might be called from ObjC code that doesn't fulfill its nullability promises in practice. Fixes SR-7240 | rdar://problem/38675815.
This allows them to be used in generic arguments for NSArray et al.
We already do this for the ones that wrap bridged values (like
NSString/String), but failed to do it for objects that /weren't/
bridged to Swift values (class instances and protocol compositions),
or for Error-which-is-special.
In addition to this being a sensible thing to do, /not/ doing this led
to IRGen getting very confused (i.e. crashing) when we imported a
Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol
descriptors for imported protocols at all, because it's possible we
weren't able to import all the requirements. But that's a separate
issue.)
https://bugs.swift.org/browse/SR-6844
* First pass at implementing support for mapping between long double and Float80.
* Only define CLongDouble on platforms where I know what it is.
* remove some hacks that are no longer necessary.
We were not handling IUO results of @optional protocol methods
properly, sometimes forcing the @optional requirement rather than the
result of the call.
Fixes rdar://problem/37240984.
The importer handles these by first trying to look up the type by name
using Clang's Sema, but that lookup can cause diagnostics to be
emitted (usually availability diagnostics). We could try to figure out
how to propagate that to the macro when we import it, but for now just
drop the macro instead if there are any diagnostics emitted when
looking up the type.
This will be a small source compatibility break if anyone was using a
macro defined in terms of a type that's deprecated or that has partial
availability; the macro will now silently not be imported instead of
producing an unsilenceable warning.
rdar://problem/36528212
Rather than being smart about this, just record an import failure when
we start importing a particular macro and update it at the end. Also
add a PrettyStackTrace to make this a little easier to track down in
the future.
The old logic for importing macros that just aliased other macros
managed to handle this in a clever way, but that was never tested for
the newer logic that evaluates expressions (fa834e2f80). Macro
importing in general probably deserves some cleanup, but meanwhile we
should make sure not to crash!
rdar://problem/34986930
at AnyObject?.
Also, ensure that @convention(block) functions can be erased to
AnyObject, and teach SILGen how to do this with unchecked_ref_cast.
Fixes a source compatibility suite regression.
Also, fix some logic in the peephole that was incorrectly recognizing
T? -> U? -> AnyObject as a force instead of a request to create NSNull.
In both cases, we ought to still be able to do much better than the
unpeepholed code by just applying the peephole and then merging in NSNull
in the nil case, but in the short term we need to fix this bug.
Fixes rdar://35402853
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
When performing a lookup into a class C, we might find a member of
C that witnesses a requirement in a protocol Q that C conforms to.
In this case, AST name lookup returns both results.
There are two further levels of fitering which can eliminate the
ambiguity:
- Sema name lookup maps requirements to witnesses if the base type
of the lookup is a nominal type or a class-constrained archetype.
Imported conformances don't have this mapping recorded, but there's
another hack in this code path where if a requirement maps to
itself inside a conformance, it is dropped from the results
altogether.
- If the duplicate results were not filtered out in Sema name lookup,
there was another hack in CSRanking which would a witness higher
than it's requirement when comparing solutions. This doesn't work
for imported conformances, but usually name lookup filters out
the duplicate results sooner, which also eliminates the exponential
behavior from having multiple constraint system solutions.
However, if we have a subclass existential C & P where C conforms
to Q and we find a member of C that witnesses a requirement of Q,
then (C & P) does not conform to Q.
So if the conformance was imported, *both* of the above checks
would fail to disambiguate the witness and requirement, and the
member access would fail to type check.
To make this work with imported conformances, teach Sema name lookup
to extract the superclass from an existential before performing the
conformance check. If the conformance check fails, it means we
found the protocol member via the 'existential' part of the subclass
existential (eg, in our case, a member of P), and we proceed as
before.
Fixes <rdar://problem/33291112>.
just for pointer identity.
The current technique for deciding whether that's the case is *extremely*
hacky and need to be replaced with an attribute, but I'm reluctant to
take that on so late in the schedule. The hack is terrible but not too
hard to back out in the future. Anyone who names a method like this just
to get the magic behavior knows well that they are not on the side of
righteousness.
rdar://33265254
conversions that reverse an implicit conversion done to align
foreign declarations with their imported types.
For example, consider an Objective-C method that returns an NSString*:
- (nonnull NSString*) foo;
This will be imported into Swift as a method returning a String:
func foo() -> String
A call to this method will implicitly convert the result to String
behind the scenes. If the user then casts the result back to NSString*,
that would normally be compiled as an additional conversion. The
compiler cannot simply eliminate the conversion because that is not
necessarily semantically equivalent.
This peephole recognizes as-casts that immediately reverse a bridging
conversion as a special case and gives them special power to eliminate
both conversions. For example, 'foo() as NSString' will simply return
the original return value. In addition to call results, this also
applies to call arguments, property accesses, and subscript accesses.
Somehow the logic had slipped so that we were basing this decision purely
on the ImportTypeKind and not on whether the broader context is bridgeable.
This was allowing us to use bridged types when e.g. importing the results
and parameters of C function pointer types, which is really bad.
Also, when importing a reference to a typedef of block type, do not use
the typedef in a non-bridgeable context. We import typedefs of block type
as fully-bridged types, but this means that it is invalid to import a type
using the typedef in a context where the original C type must be used.
Similarly, make sure we use a properly-imported underlying type of the
typedef when the typedef itself is unavailable.
Also, extend the special behavior of block typedefs to abstract-function
typedefs, which seems to be consistent with the expected behavior of the
tests.
Finally, I changed importType to take a new Bridgeability enum instead of
a raw canFullyBridgeTypes bool. At the time, I was doing that because I
was going to make it tri-valued; that turned out to be unnecessary, but I
think it's an improvement anyway.
The framework versions already superseded the files here, so let's not
even bother building and packaging them. There /are/ still a few
frameworks that aren't shipping their own API notes at the moment,
however, though some of them are deprecated in their entirety.
rdar://problem/32908357
Ever since we stopped associating the top-level struct of an imported
NS_ERROR_ENUM with the Clang enum declaration, we've been unable to
print imported NS_ERROR_ENUMs. The module-printing infrastructure
would drop them thinking they aren't imported declarations.
This also affected NS_ERROR_ENUMs that were imported as members of
another type, as well as other types imported as members.
Fixes rdar://problem/32497693.
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
