Now we initialize the array buffer from sequences using unsafe pointer
arithmetic, which avoids extra retain/release traffic. But since the
size of the sequence is not known in advance, we only initialize as much
as underestimateCount() promises, and fall back to the slow approach for
the tail. Nevertheless, for collections, where the size is known
precisely, this technique is suboptimal only by one branch.
rdar://20530390
Swift SVN r27380
This doesn't actually break the circular type-checking issues with
have with associated type inference, but it makes them less
painful. Fixes rdar://problem/20549165.
While here, and as a test, remove the _prext_underestimateCount
workound from the library. _CollectionDefaultsType now refines
_SequenceDefaultsType.
Swift SVN r27368
@objc protocols aren't supported with an ObjC runtime, but we still want values of AnyObject type to be word-sized. Handle this by turning the binary "needsWitnessTable" condition into a "dispatch strategy" enum, so we can recognize the condition "has no methods, so neither swift nor objc dispatch" as distinct from either swift or ObjC protocol representations. Assign this dispatch strategy when we lower AnyObject. Should be NFC for the ObjC-enabled build.
(It would also be beneficial for the ObjC-runtime-enabled version of Swift if AnyObject weren't an @objc protocol; that would mean we could give it a canonical protocol descriptor in the standard library, among other things. There are fairly deep assumptions in Sema that AnyObject is @objc, though, and it's not worth disturbing those assumptions right now.)
Reapplying with updates to the runtime unit tests.
Swift SVN r27341
@objc protocols aren't supported with an ObjC runtime, but we still want values of AnyObject type to be word-sized. Handle this by turning the binary "needsWitnessTable" condition into a "dispatch strategy" enum, so we can recognize the condition "has no methods, so neither swift nor objc dispatch" as distinct from either swift or ObjC protocol representations. Assign this dispatch strategy when we lower AnyObject. Should be NFC for the ObjC-enabled build.
(It would also be beneficial for the ObjC-runtime-enabled version of Swift if AnyObject weren't an @objc protocol; that would mean we could give it a canonical protocol descriptor in the standard library, among other things. There are fairly deep assumptions in Sema that AnyObject is @objc, though, and it's not worth disturbing those assumptions right now.)
Swift SVN r27338
This allows array types to get the best performance. The default
implementation for range replaceable collections appends elements one by
one, and the optimizer can't hoist uniqueness checks from the loop in
that case yet.
Swift SVN r27314
Array(other_collection) is using an optimized code path for copying
collections. An explicit for loop does not.
This commit should recover the performance regression in
rdar://20530390.
Swift SVN r27313
We may want to use optimized ErrorType representations that don't naturally "become" NSErrors, such as tagged-pointer representations of small error enums, or a tagged function pointer to a deferred error type constructor. Rename the runtime function to something a bit more descriptive of its real purpose, not its implementation.
Swift SVN r27209
When calling _getOwner at this point we know that it is a native array.
This simplifies the SIL code for assigning a class array element (a[i] = x).
Swift SVN r27124
We define two new library functions _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC, similar to _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC. The main difference is that they require their arguments to conform to _BridgedToObjectiveC and _BridgedToObjectiveC. _ObjectiveCType accordingly. With this change, it is now possible to invoke the _BridgedToObjectiveC._forceBridgeFromObjectiveC witness directly, without going via the inefficient swift_bridgeNonVerbatimFromObjectiveC.
So now, for a cast O -> S, if it can be statically proven that an ObjC type O is bridgeable to a Swift type S implementing the _BridgedToObjectiveC protocol (i.e. O is the class (or its subclass) defined by the S._ObjectiveCType alias), we can generate a code to invoke the newly defined library function _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC instead of _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC.
After inlining, this will end-up invoking S._forceBridgeFromObjectiveC directly instead of invoking a more general, but less effective swift_bridgeNonVerbatimFromObjectiveC, which always performs conformance checks at runtime, even if conformances are known statically. As a result, no conformance checks are performed at run-time if conformances are known statically.
The client code making use of these new APIs and the tests are coming in the subsequent commits.
The naming of the two new helper library functions was discussed with Dmitri.
This is part of the bridging casts optimization effort. And it is specifically useful for e.g. rdar://19081345.
Swift SVN r27100
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r27092
The new mirror design passed our API review and blocking bugs have been
fixed/worked-around, so integrating it into the core standard library.
Swift SVN r27082
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r27081
If the NSError part of the box hasn't been initialized yet, fill it in with the domain and code of the contained value. This will allow us to efficiently turn ErrorType values into NSErrors, either for bridging or for coercion purposes.
Swift SVN r26958
