The stdlib uses this condition to recognize types that represent classes without representation changing, which isn't true for metatypes. They will natively be pointers to the Swift type metadata instead of the ObjC class object, so a conversion step is necessary. This doesn't directly fix container bridging, but it prevents the runtime from trying to bridge verbatim metatypes without first changing them to ObjC representation.
Swift SVN r29998
Implement casting support for taking an AnyObject and conditionally converting it to a T.Type for some class type. Fix some memory management bugs too, where we used swift_release to release an object not known to have Swift refcounting. This mostly fixes rdar://problem/16238475, though the SIL optimizer still improperly folds away attempted casts from NSObject to a class metatype, and I haven't yet validated bridging support for NSArray<Class>*.
Swift SVN r29956
This is a straight-up "oops". You could always get to these typealiases via
the protocol, but like the member requirements you should have to say so.
Swift SVN r29952
Revert "simd overlay: Use LLVM vector types."
This reverts commit r29922 and r29924.
More arm64 instruction selection errors.
rdar://21703486
Swift SVN r29941
The way we pass and compose source locations, messages, etc. needs to be
brought under control before too many more tests get written. This is
the first step.
Swift SVN r29928
Remove these standard library types in favor of (T) -> () closures.
It was originally believed that generic optimizations would make these
types profitable, however:
// FIXME: Insert benchmarks here.
rdar://problem/21663799
Swift SVN r29927
This brings the David Owens benchmark from http://owensd.io/2015/06/27/performance-xcode7-beta-2.html from parity with simd.h-based C to 3x faster.
Before:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 7.035851 │ 6.304739 │ 9.815832 │ 1.212 │
After:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 2.318357 │ 2.223325 │ 2.697981 │ 0.1490 │
This also addresses rdar://problem/21574425, since Builtin.add_VecNxIntM isn't overflow-checked, and overflow checks really aren't wanted when working with vector types directly.
Reapplying now that Nadav's fixed the ARM64 SelectionDAG issue this exposed before.
Swift SVN r29922
Add a shared buffer to every range replaceable mutable collection to
track logical mutations, and invalidate all indices on every mutation.
Swift SVN r29917
- Clean up tests
- Create API-specific test structures with clearer labels
- Use `OpaqueValue`s in test collections
- Make tests non-generic to allow array literal declarations
- Remove some unused functions
- Test return values for mutating functions that return a value
- Add expect* test source locations
- Add _customRemoveLast ad-hoc default implementation for `removeLast`
- Add default implementation for reserveCapacity that does nothing.
Swift SVN r29905
This brings the David Owens benchmark from http://owensd.io/2015/06/27/performance-xcode7-beta-2.html from parity with simd.h-based C to 3x faster.
Before:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 7.035851 │ 6.304739 │ 9.815832 │ 1.212 │
After:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 2.318357 │ 2.223325 │ 2.697981 │ 0.1490 │
This also addresses rdar://problem/21574425, since Builtin.add_VecNxIntM isn't overflow-checked, and overflow checks really aren't wanted when working with vector types directly.
Swift SVN r29891
It was neither testable (because it was internal) nor usable (because in
practice models would be full of ambiguities with methods provided in
extensions for CollectionType.
Swift SVN r29859
ExtensibleCollectionType's operations can all be represented by the
primitive range replacement operation, so fold it into
RangeReplaceableCollectionType.
In addition, provide default implementations of
RangeReplaceableCollectionType's methods.
- New tests added for combinations of (static, generic) calls and
(default, custom) implementations.
- Mark free Swift functions as unavailable with a message to direct the
developer to the protocol methods.
- Mark ExtensibleCollectionType as available with a message added to
direct the developer to the right protocol.
rdar://problem/18220295
Swift SVN r29857
These form an important part of the basis of the new lazy sequence
system. Tests for _CollectionWrapperType are currently blocked on
<rdar://problem/21599265>
Swift SVN r29814
...instead of ObjectIdentifier, to wrap Any.Type, and add protocol
conformances. ObjectIdentifier doesn't print nicely, because there's
really no type information left, and TypeIdentifier makes for better
output when tests fail.
Swift SVN r29813
This API was added by mistake, and the type alias should have been
called ``Generator``. In fact, a nested type alias is already inferred
to satisfy the associated type ``Generator`` in Set's ``SequenceType``
conformance.
rdar://20171363
Swift SVN r29796
This approach should help us massively reduce the amount of code it
takes to verify that the architecture of our protocols works as
expected. Pair-programmed with Dmitri Hrybenko.
Swift SVN r29752
