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
Add a shared buffer to every range replaceable mutable collection to
track logical mutations, and invalidate all indices on every mutation.
Swift SVN r29917
expressions. Broadening from callexpr to apply expr (picking up operators) improves
several diagnostics in the testsuite, and is important to avoid regressions from an
upcoming patch.
Swift SVN r29821
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
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
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
