When determining whether a given normal protocol conformance is “retroactive”,
consider an overlay module to be equivalent to its underlying Clang module.
Therefore, don’t classify conformances within the overlay as “retroactive”,
simplifying some common manglings (e.g., NSObject’s Hashable conformance is
no longer considered retroactive) and better capturing the intent.
Karoly removed the last use of _convertStringToNSString in f2a96496a;
the replacement is referenced by the runtime but not by the compiler.
Doug had removed all the others from the stdlib in d92ae7707.
rdar://problem/35230338
This lets us eliminate the _getObjectiveCType() value witness, which
was working around the lack of proper type witness metadata in witness
tables. Boilerplate -= 1.
Extend the use of
_ObjectiveCBridgeable._unconditionallyBridgeFromObjectiveC to all
bridged types rather than using the custom entry points. Note that
there is a lot of hackery around ensuring that the conformance is
correct, because Sema needs to anticipate that SILGen (or later SIL
passes) might need those conformances. This primarily affects the
overlays, but with generalized bridging that means any mixed
Objective-C/Swift framework with bridged types.
This reverts commit 052d2d0a69.
The only actual issue with the original change was a missing change to
the UIApplicationMain SILGen test, which needs to build SILGen
overlays to execute properly; -enable-source-import doesn't suffice.
Introduce a new entrypoint to _ObjectiveCBridgeable,
_unconditionallyBridgeFromObjectiveC, which handles unconditional
bridging from an optional Objective-C object (e.g., an NSString) to
its bridged Swift type. Use it in SILGen to perform NSString -> String
bridging rather than the custom entry point.
Another small step toward generalized bridging.
Provide a general mechanism for bridging from a Swift value type to
its corresponding Objective-C class type through the
_bridgeToObjectiveC witness of the appropriate _ObjectiveCBridgeable
protocol conformance. Only enable this new code for bridging String ->
NSString and work through the issues that crop up.
We cannot actually *delete* the _convertStringtoNSString entrypoint
yet, because there is some code that is depending on it indirectly;
I'll address that separately as part of the continued generalization
of the _ObjectiveCBridgeable mechanism.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
- 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 internal details of ErrorType are still being designed.
They should be underscored in the meantime to
indicate they are still evolving.
Implements rdar://problem/20927102.
Swift SVN r28500
The string version of r26479. There's a lot of backstory and justification
there, so just read that commit message again. The one addition for String
is that global NSString constants are loaded as String as well, so that
also has to go through the bridging code even though there's no function
call involved.
Finishes rdar://problem/19734621.
Swift SVN r26510
...and similar for NSDictionary and NSSet.
For APIs that don't have a reason to distinguish "empty" and "absent" cases,
we encourage standardizing on "empty" and marking the result as non-optional
(or in Objective-C, __nonnull). However, there are system APIs whose
implementations currently do return nil rather than an empty collection
instance. In these cases, we recommend /changing/ the API to return the
appropriate "empty" value instead.
However, this can cause problems for backwards-deployment: while the API is
truly non-optional on system vN, a program may encounter a nil return value
if run on system vN-1. Objective-C can generally deal with this (especially
if the only thing you do is ask for the count or try to iterate over the
collection) but Swift can't. Therefore, we've decided to "play nice" and
accept nil return values for the collection types (NSArray, NSDictionary,
and NSSet) and implicitly treat them as "empty" values if they are the
result of an imported function or method.
Note that the current implementation has a hole regarding subscript getters,
since we still make an AST-level thunk for these in the Clang importer.
We can probably get rid of those these days, but I didn't want to touch
them at this point. It seems unlikely that there will be a subscript that
(a) is for a collection type, and (b) mistakenly returned nil in the past
rather than an empty collection.
There's another hole where an ObjC client calls one of these mistakenly-nil-
returning methods and then immediately hands the result off by calling a
Swift method. However, we have to draw the line somewhere.
(We're actually going to do this for strings as well; coming soon.)
rdar://problem/19734621
Swift SVN r26479
rdar://problem/19132138
Make Set<T> visible by removing the underscore. Also, remove the pesky
${_Self} gyb variable that was for a temporary convenience in hiding Set.
Swift SVN r23699
The _forceBridgeFromObjectiveC and _conditionallyBridgeFromObjectiveC
requirements of the _ObjectiveCBridgeable protocol previously returned
Self and Self?, respectively, where 'Self' is the value type that is
bridged. This use of returns is fairly hostile to the idea of calling
the witnesses for these requirements from the C++ part of the runtime,
leading to "interesting" tricks with OpaqueExistentialContainer that
made it hard to use these witnesses within the dynamic casting
infrastructure.
Replace the returns with inout Self? parameters, which are far easier
to deal with in the C++ part of the runtime. Despite the churn because
we're changing the _ObjectiveCBridgeable protocol, this is NFC.
Swift SVN r20934
Squash _[Conditionally]BridgedToObjectiveC into one protocol. This
change results in simpler bridging code with fewer dynamic protocol
conformance checks, and solves the nasty naming/semantics problem that
resulted from having _ConditionallyBridgedToObjectiveC refining
_BridgedToObjectiveC.
Also, rename things so they're more symmetrical and less confusing.
Swift SVN r20664
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
Previously, a forced downcast was implemented as a conditional
downcast following by an implicit unwrap, and relied on peephole
optimizations (in both constraint application and SILGen) to turn them
into a forced downcast. However, these didn't kick in for AnyObject ->
T[] downcasts, bypassing the more-efficient deferred checking our
native collections can do. Finishes <rdar://problem/17319154>.
Swift SVN r19064
Now that we use bridgeFromObjectiveCConditional to perform conditional
bridging, make bridgeFromObjectiveC handle forced bridging. For the
latter, deferred checking is acceptable.
Almost all of <rdar://problem/17319154>.
Swift SVN r19046
Also, don't allow file-relative imports (i.e. don't consider a /source file's/
location as an include path). Both of these should be requested by the user,
at least at this point.
Swift SVN r13249
