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
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
- 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
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
Eliminates _CollectionDefaultsType and _CollectionGeneratorDefaultsType
and creates sanity that should allow us to Protocol Extension-ize the
lazy operations, which have been blocked on inscrutable errors due in
part to the existing complexity.
Note: names beginning with "_prext_" are intended to be public after API
review and removal of the "_prext_" prefix.
Swift SVN r29689
struct ReverseIndex<Base : BidirectionalIndexType> { ... }
struct ReverseRandomAccessIndex<Base : RandomAccessIndexType> { ... }
// Renamed from `BidirectionalReverseView`.
struct ReverseCollection<Base : CollectionType where T.Index : BidirectionalIndexType> { ... }
// Renamed from `RandomAccessReverseView`.
struct ReverseRandomAccessCollection<Base : CollectionType where T.Index : RandomAccessIndexType> { ... }
Also fixed a bug (found by the new tests I added in this commit) in
LazyRandomAccessCollection.reverse(), which mistakenly returned a bidirectional
reversed collection.
Part of rdar://21429126
Swift SVN r29634
... for AnyGenerator, AnySequence, AnyForwardCollection,
AnyBidirectionalCollection, AnyRandomAccessCollection.
Part of rdar://21429126
Swift SVN r29628
