This also reverts the commit "stdlib: Don't check for overflow in subscript accesses to
ContigousArrayBuffer" as removing the overflow check on all unsafe pointers has
the same effect.
Swift SVN r21220
We overflow checked the mulitplication in "a + sizeof(T) * i". This is not
necessary for ContingousArrayBuffer because this overflow check has happened
when we compute the size of the array during allocation of a native swift array
or a NSArray.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
Memset`````````````````,``1184.00```,``487.00```,``698.00``,````````143.9%
QuickSort``````````````,``1299.00```,``1458.00``,``178.00``,````````-12.2%
SelectionSort``````````,``1027.00```,``814.00```,``213.00``,````````26.2%
StdlibSort`````````````,``1718.00```,``1587.00``,``127.00``,````````8.0%
Walsh``````````````````,``1160.00```,``1076.00``,``86.00```,````````8.1%
XorLoop````````````````,``1248.00```,``884.00```,``369.00``,````````42.0%
The regression in quicksort is noise - i looked at the LLVM IR and the only
thing different in the graph is that we have removed the mulitplication with
overflow check (that is - we should be running faster). Same thing looking at
the assembly.
XorLoop and Memset speed up because we are now able to vectorize those loops.
Swift SVN r21218
To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
In answering a forum post I noiced that I wanted this and it was
missing.
Also, extensive comments
Also, rename the length: init parameter to count:. When writing the
comments for the init function it became painfully clear why we use
"count" is better than "length" especially around pointers and memory:
the former is much less easy to mistake for "length in bytes". Plus
it's consistent with the new ".count" property
Swift SVN r20609
Ultimately this gets to HeapBuffer which checks the index is in range by separately checking whether the storage is nil, then the index is less than the count
Swift SVN r20363
Arrays of non-verbatim-bridged types (such as Int, and today's String)
are converted to Objective-C lazily, with the objects created due to
element conversion being autoreleased when necessary.
Fixes <rdar://problem/17360154>
Note: test/SIL/Parser/array_roundtrip.swift was XFAIL'd;
see <rdar://problem/17758203>
Swift SVN r20293
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
ArrayBuffer
ArrayBufferType
ContiguousArrayBuffer
ContiguousArrayStorage
IndirectArrayBuffer
SliceBuffer
Unfortunately, can not remove 'public' from them since they are used by
Foundation overlay in bridging code.
Swift SVN r19810
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
Until we get an optimizer pass to remove get/set pairs, passing a
property that is a protocol requirement as inout from generic code is
always going to cause an extra retain, causing many unintended Array
copies.
Because this dropped reference counts to 1 in some cases, it exercised
previously-untested code paths and uncovered bugs, particularly in the
handling of subrange replacement on Slice<T>.
There are still differences in speed for short arrays of CGPoint that bear
investigation, but at least as things scale up, the ratio of time goes
to 1.
Fixes <rdar://problem/17040913> append and += on an array have
completely different performance
Swift SVN r19228
Because _demandUniqueMutableBuffer returns nil if the buffer already
exists, rename to _createUniqueMutableBuffer.
Because _requestUniqueMutableBuffer may return native backing storage
for a slice whose bounds don't exactly match the backing storage, rename
to _requestUniqueMutableBackingBuffer
Swift SVN r19214
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
Revert "[stdlib] Use an enum for ArrayBuffer storage"
This reverts commit r18996.
This reverts commit r18954.
The optimizer is not ready yet to handle this change especially given
the time until Beta 3. After speaking with DaveA, we agreed to revert
this and take such large changes onto private branches until we are sure
that the optimizer is ready to handle them rather than risking
performance regressions due to hitting the "optimization cliff".
Swift SVN r19026
This enables testing of other growth factors, per
<rdar://problem/17230502>. See the radar for basic performance test
results confirming (to the degree practical) that 2x growth is better
than 1.5x in our current system.
Swift SVN r18990
instead of reinterpretCasting all over the place. This should make it
easier on the ARC optimizer.
Addresses <rdar://problem/17312221>
Swift SVN r18954
This helps array append's performance by ~ 2x. The generic max with a variadic
argument creates a temporary array then iterates over the array.
rdar://17140639 rdar://17073827
Swift SVN r18764
so I took the liberty to 'privatize' them with a leading underscore.
This also completely removes '_ArrayBody' from the public interface.
Should be NFC, apart from the public interface change.
Swift SVN r18625
Before this change, the dispatching hacks sent convertFromArrayLiteral
through the "Sequence" path, wherein we could not assume the ability to
non-destructively measure the length of the Sequence before beginning to
add the elements, which resulted in buffer reallocations as elements
were added. Now we the sequence is measured and storage is
pre-allocated.
Swift SVN r18603
and alignment for the purposes of deallocation.
If a class contains a method named __getInstanceSizeAndAlignMask,
and it takes no arguments and returns a pair of words, call
that method directly in order to get the size and alignment
mask instead of trusting the class's formal size and alignment.
This is not a replacement for a proper language solution for
custom allocation, but it'll suffice to fix some immediate
problems with HeapBufferStorage.
If we decide we like this approach, we should really raise
the deallocating destructor up to SIL.
rdar://16979846
Swift SVN r18485
Added a workaround for <rdar://problem/16953026> that allows them to
pass and flipped the sense of a test that was failing because we can now
downcast an Array that we couldn't downcast before.
Swift SVN r18319
assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
