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
lvalues when compiling list of partial-match overloads in diagnosis.
(This is a reapplication of commits r29462 and r29469.)
Also, fix the following tests:
stdlib/FixedPointDiagnostics.swift.gyb
stdlib/NumericDiagnostics.swift.gyb
<rdar://problem/17875634> can't append to array of tuples
Swift SVN r29493
Some test cases where assuming to be compiled in Debug assert configuration.
The test relies on return autorelease optimization to happen. This does not
happen reliable in optimize mode.
I ran the test case under the leaks runner and no leaks are reported yet the
object count is positive. This can happen if some objects are still in a
autorelease pool at the time we count them. Which seems to happen.
I surrounded the code with "autoreleasepool {}" and it would pass which confirms
this assumption. I have looked at both the generated LLVM IR and the otool -tvV
asssembly output and did not see anything that would block the return
autorelease optimization (i.e instructions between the returnautorelease
function call and the retain_returnautorelease call) so I don't believe there is
something the compiler could do better.
rdar://21193916
Swift SVN r29369
The protocol is still needed in order to make sure mixed signed/unsigned
arithmetic doesn't compile, but after pulling all its "real"
requirements into UnsignedIntegerType, that's now its only function.
Thus, rename it to _DisallowMixedSignArithmetic.
Swift SVN r28980
It takes a long time to compile (at least partly due to rdar://problem/20875936)
and then takes a long time to run (because it's a very large collection of
test cases). Dmitri says he prefers not to split it up into multiple tests.
This cuts my debug compiler / debug stdlib local testing time by over 15%.
Swift SVN r28811
