Added a workaround for <rdar://problem/16953026> that allows them to
pass and flipped the sense of a test that was failing because we can now
downcast an Array that we couldn't downcast before.
Swift SVN r18319
upcasts."
Reinstate "Restrict the array-bridged conversion to non-verbatim
bridging."
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Move _arrayBridgedDownCast to Foundation"
Reinstate "Replace "can" with "cannot" in a message."
Reinstate "Implement support for non-verbatim T[] -> AnyObject[]
upcasts."
This reinstates commit r18291.
This reinstates commit r18290.
This reinstates commit r18288.
This reinstates commit r18287.
This reinstates commit r18286.
This reinstates commit r18293.
This reinstates commit r18283.
John fixed the issue in r18294.
Swift SVN r18299
Revert "Restrict the array-bridged conversion to non-verbatim bridging."
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Move _arrayBridgedDownCast to Foundation"
Revert "Replace "can" with "cannot" in a message."
Revert "Implement support for non-verbatim T[] -> AnyObject[] upcasts."
This reverts commit r18291.
This reverts commit r18290.
This reverts commit r18288.
This reverts commit r18287.
This reverts commit r18286.
This reverts commit r18293.
This reverts commit r18283.
Sorry for the number of reverts, but I needed to do this many to get a clean
revert to r18283.
Swift SVN r18296
One of my recent type-checker changes starting passing all array
upcasts, including "bridged" ones like String[] -> AnyObject[],
through the library entry point _arrayUpCast, which is only meant for
class/ObjC existential types that are bridged verbatim.
Fixes part of <rdar://problem/16952238>; more cleanup to follow.
Swift SVN r18283
assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
creating a Dictionary from a dictionary literal
Also fixes rdar://16876745, because once the code moved to using lower-level
interfaces, it became trivial to detect duplicate keys without a performance
hit.
Swift SVN r18193
We decided that classes and Objective-C existentials are always going
to be bridged verbatim, ignoring any _BridgedToObjectiveC conformances.
While the compiler isn't preventing conformance of a class type to
_BridgedToObjectiveC, we ignore this case and will find a way to lock
it down if _BridgedToObjectiveC loses its underscore.
The motivation here is that (1) we don't really have a use case for a
class that bridges to Objective-C in any way other than just being an
Objective-C class, and (2) the class-or-ObjC-existential check is
ridiculously cheap compared to the
thread-safe-hash-table-over-a-dlsym-call used to find witness tables,
so do the cheap, common check first.
Swift SVN r18177
This method returns a proxy object. Swift cannot current cast proxy objects
to their proxied types. The workaround for now is to add a generic overlay
for -prepareWithInvocationTarget: so the declared type of the returned
proxy is the proxied type. This is good enough to make undo proxies work with
objc-dispatched calls.
Swift SVN r18155
Empty NSArrays are usually represented by emptyNSSwiftArray, whose
element type is irrelevant. So when doing a getObjects:range: on that,
presumably the range's length is zero and we shouldn't do any sanity
checking w.r.t. the element type.
Fixes <rdar://problem/16914909> Assertion failed attempting to append
arrays when subclassing Cocoa class
Swift SVN r18110
String interpolation invokes convertFromStringInterpolationSegment() function
now. There is no need to add extensions to String to allow custom types to
participate in string interpolation. Just implementing Printable will do the
right thing.
Swift SVN r18104
I didn't want to rip this logic out wholesale. There is a possibility
the character lexing can be reborn/revisited later, and
disabling it in the parser was easy.
Swift SVN r18102
