This was causing issues where the compiler rejected overrides of
imported members as being non-ObjC-compatible, even though the type
was exactly the same as what the Clang importer was using.
https://bugs.swift.org/browse/SR-2344
Even if the method is marked override we need to emit an objective C method
call.
There is no v-table guarantee because of the override keyword. The base class
method might be in an objective c class.
rdar://27389992
When a parameter has distinct "nil" and "empty" values, "nil"
generally represents the default settings, while "empty" is
explicitly cleared.
rdar://problem/27196867
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.
This improves MaterializeForSetEmitter to support emission
of static materializeForSet thunks, as well as witnesses.
This is now done by passing in a nullptr as the conformance
and requirement parameters, and adding some conditional code.
Along the way, I fixed a few limitations of the old code,
namely weak/unowned and static stored properties weren't
completely plumbed through. There was also a memory leak in
addressed materializeForSet, the valueBuffer was never freed.
Finally, remove the materializeForSet synthesis in Sema since
it is no longer needed, which fixes at least one known crash
case.
Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
- If a @convention(block) function parameter was also marked @noescape, then during type-checking, we would accidentally propagate the convention directly onto a literal closure expr, instead of going through a function_conversion, which SILGen didn't handle. Fixes rdar://problem/23261912.
- If an Objective-C API declared a block parameter with a _Nonnull return of a bridged type, such as NSString *_Nonnull, then native-to-bridged thunking would fail to recognize this case, since we still bridge to an Optional type in the lowered ObjC interface. Fixes rdar://problem/23285766.
The @objc method argument bridging did the right thing but for
func to block thunks we didn't handle optionals and IUOs.
Symptoms included memory leaks because IRGen would later try to
retain the block by calling Block_copy() and discarding the result,
or memory corruption because the on-stack block could outlive
its stack frame.
Fixes <rdar://problem/22471309>.
Swift SVN r31882
This re-applies commit r31763 with a change to the predicate we
use for determining the linkage of a definition. It turns out we
could have definitions with a Clang body that were still public,
so instead of checking for a Clang body just check if the Clang
declaration is externally visible or not.
Swift SVN r31777
If an external SIL function has a Clang-generated body, I think this
means we have a static function, and we want to use Shared linkage,
not Public.
Add a new flag to SILFunction for this and plumb it through to
appease assertions from SILVerifier.
Swift SVN r31763
The old code predates NumberLiteralExpr having a "negative" field.
Fixing this avoids creating a temporary signed integer with a value of
INT_MAX+1 when trying to compute INT_MIN.
rdar://problem/21680700
Swift SVN r30814
There's a hack to make closures in transparent contexts always public in order to support transparent inlining in user code, but it's the wrong thing to do with the artificial callback for materializeForSet, which will be generated in modules that need it. Any problems with this linkage would already be problems with referencing the other shared accessors, and this fixes a duplicate symbol bug when materializeForSet is demanded by multiple TUs (rdar://problem/21314681).
Swift SVN r30098
Per discussion, there are certain times where our APIs really want you to use
the performSelector family of methods (e.g. when the framework hands you a selector
and expects you to call it upon completion).
Although the methods still aren't type-safe, we are at least making the result
Unmanaged so that you're forced to think about whether it's +1 or +0 before you
use it, and so that the compiler doesn't accidentally try to retain a non-object
pointer.
This commit also removes the blocks on the makeObjectsPerformSelector... methods,
but Foundation plans to add NS_SWIFT_UNAVAILABLE there (see rdar://problem/21150180).
rdar://problem/21150277
Swift SVN r30044
This allows SILGen to recognize them as foreign declarations, fixing a bug when classes with subscripts defined in Objective-C were extended to conform to Swift protocols with subscript requirements. rdar://problem/20371661
Swift SVN r27998
Import our fake Foundation rather than redeclaring NSString in SILGen's
fake "gizmo" module...then fix up other tests to more carefully use SILGen's
mock SDK in avoiding the real set of overlays...using -enable-source-import.
In the mid-term SILGen should probably switch to using the shared
clang-importer-sdk in test/Inputs/. In the long term we need that to be
using proper modules too rather than -enable-source-import.
No intended functionality change, but without this the next commit breaks
things (because members are deserialized less eagerly).
Swift SVN r27195
We have an SPI between the Swift compiler and Foundation based on the
SWIFT_SDK_OVERLAY_FOUNDATION_EPOCH preprocessor macro that allows us to
request the new API. rdar://20270080 tracks removing it.
Swift SVN r26475
Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
This time, update test/SILGen/objc_properties.swift to avoid a false negative test failure.
Swift SVN r24888
Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
Swift SVN r24882
attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
It's not always correct to map a Swift Bool back to ObjCBool in C land, since Bool could have originally been a proper _Bool. Pass the clang::Decl down to type lowering so we can recognize this. We still don't have a great solution for block types, because there's no decl to refer to, and Swift's user-level type system erases the distinction between void(^)(_Bool) and void(^)(BOOL). However, this is enough to let us start using C APIs that traffic in _Bool.
Swift SVN r23546
In particular, observing overrides of Objective-C properties in extensions
were getting non-dynamic accessors synthesized.
rdar://problem/18213447
Swift SVN r22107
This behaves like @UIApplicationMain, except for AppKit. Attach it to your NSApplicationDelegate, and an artificial "main" will be generated that invokes NSApplicationMain() for you. Implements rdar://problem/16904667.
Swift SVN r21697
A "super" expression may refer not only to a super instance object, but a super metatype object as well. Fixes rdar://problem/17599865.
Swift SVN r21559
r21096 introduces an optimization barrier for failing initializers
that allows the pattern
let x: NSFoo? = NSFoo()
be used to detect whether NSFoo() returned nil, even though the type
system says it cannot. Extend this check to Objective-C methods and
properties, where the non-optional annotation may be incorrect
<rdar://problem/17984530>.
Swift SVN r21176
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
We now allow bridging so long as both K and V can be bridged to
Objective-C, as determined by _BridgedToObjectiveC conformance. Note
that Dictionary's implementation still needs to handle this, which is
tracked separately.
Swift SVN r17859
