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
Previously, we had a predicate that only worked properly for 64-bit
architectures; the 32-bit platforms don't have tagged pointers, and
have an annoying tendency to allocate objects with the high bit of the
address set. Fixes <rdar://problem/17544277>.
Swift SVN r19523
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
This entry point is used in conditional downcasts (as?) to attempt to
bridge from an Objective-C class down to a specific native type (e.g.,
array, dictionary), bridging all elements eagerly so that it can
produce nil if the bridging would fail.
This is the scaffolding for <rdar://problem/17319154>, and makes the
example there work, but there is much more cleanup and optimization to
do.
Swift SVN r18999
This is the most general dynamic cast operation, permitting
arbitary source and destination types and handling arbitrary
changes in representation. A value of the destination type
is constructed in an address provided by the caller; flags
control the behavior w.r.t. the source value.
Not yet used; probably buggy in various particulars.
Swift SVN r18815
put the result in a different place.
WIP: no IRGen support yet.
This will eventually be the required form when casting
to an address-only type; the existing instructions will
have only scalar outputs.
Swift SVN r18780
dynamicCastClass assumes that the destination type is a
Swift class type.
dynamicCastObjCClass assumes that the destination type is
an ObjC class type (represented as ObjC metadata, not type
metadata).
dynamicCastUnknownClass assumes only that the destination
type is some kind of class.
Swift SVN r18776
