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
To facilitate the removal of the BooleanType conformance from Optional<T>, we'll first need to support
equality comparisons between the 'nil' literal and optionals with non-equatable element types.
We can accomplish this via three changes:
- New overloads for "==" and "!=" that we can resolve against non-equatable optionals
- A tweak to our overload resolution algorithm that, when all other aspects of two overloads are
considered equal, would favor the overload with a more "constrained" type parameter. This allows
us to avoid ambiguities between generic overloads that are distinct, but whose parameters do not
share a pairwise subtype relationship.
- A gross hack to favor overloads that do not require bindings to 'nil' when presented with an
otherwise ambiguous set of solutions. (Essentially, in the face of a potential ambiguity, favor solutions
that do not require bindings to _OptionalNilComparisonType over those that do.)
The third change is only necessary because we currently lack the ability to specify "negative" or
otherwise more expressive constraints, so we'll want to rethink the hack post-1.0. (I've filed
rdar://problem/17769974 to cover its removal.)
Swift SVN r20346
Lift the precondition that contiguous storage already exist on the use
of Array.withUnsafe[Mutable]PointerToElements. Automatically guarantee
that storage is unique when using the mutable variants of these methods.
Also, fix some---essentially---inout aliasing violations in
test/stdlib/Unicode.swift that were revealed by the new careful
implementation of these methods.
Swift SVN r20339
The global first() and last() algorithms return T?, nil when empty
All .first() and .last() methods became T? vars that are nil when the
Collection is empty
Swift SVN r20326
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
+= only extends arrays with another sequence of the same element type.
Fixes <rdar://problem/17151420> The use of the overloaded += operator in
Swift is inconsistent and confusing with Arrays.
Note that this commits generated 3 new radars against the type checker:
<rdar://problem/17751308>
<rdar://problem/17750582>
<rdar://problem/17751359>
Swift SVN r20274
Primarily, this means becoming resilient to Builtin.strideof(x) == 0.
Pretty much the only way to get pointers and arrays to make sense is to
treat zero-sized elements as having a stride of 1, so we do that in our
wrapper for Builtin.strideof. Other points include precondition checks
for radixes in number formatting.
Fixes <rdar://problem/17097768>
Swift SVN r20242
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
Even if the user supplies an ordering predicate that isn't a strict-weak
ordering, algorithms should not index beyond their bounds. Otherwise, a
use of withUnsafeMutableStorage for optimization purposes could easily
do an unsafe memory access.
This commit comments and tests our algorithms that require strict weak
orderings, and fixes safety problems in partition(). Most benchmarks
are unaffected, but the rewrite of partition produces a 27% speedup in
the Phonebook benchmark at -O3 and a 22% speedup at -Ofast.
Also, at -Ofast, QuickSort lost 6% and RC4 gained 6%. These benchmarks
were not noticeably affected at -O3
====================`PrecommitBench_O3`====================
````benchmark`,`baserun0`,`baserun1`,`baserun2`,``optrun0`,``optrun1`,``optrun2`,``delta`,`speedup`
````Phonebook`,``1608.00`,``1676.00`,``1651.00`,``1265.00`,``1278.00`,``1281.00`,`343.00`,```27.1%`
````QuickSort`,```430.00`,```448.00`,```429.00`,```428.00`,```431.00`,```428.00`,```1.00`,````0.2%`
``````````RC4`,```925.00`,```924.00`,```922.00`,```916.00`,```919.00`,```917.00`,```6.00`,````0.7%`
====================`PrecommitBench_Ofast`====================
````benchmark`,`baserun0`,`baserun1`,`baserun2`,``optrun0`,``optrun1`,``optrun2`,``delta`,`speedup`
````Phonebook`,``1521.00`,``1546.00`,``1591.00`,``1252.00`,``1255.00`,``1256.00`,`269.00`,```21.5%`
````QuickSort`,```478.00`,```477.00`,```476.00`,```506.00`,```510.00`,```513.00`,``30.00`,```-5.9%`
``````````RC4`,``1033.00`,``1874.00`,``1030.00`,```974.00`,```982.00`,```975.00`,``56.00`,````5.7%`
Swift SVN r20202
Add a set of _preconditionOptionalHasValue intrinsics that merely test that an optional has a case. Emit an lvalue ForceValueExpr as a physical lvalue, first asserting the precondition then projecting out the Some payload.
Swift SVN r20188
We've decided resilience is wrong for Swift given current constraints;
see rdar://problem/11940897 for more detail.
This reverts commit r20052
Swift SVN r20127
It wasn't properly handling the cases where the bound was in the
opposite direction from the amount, when advancing random access
indices.
Swift SVN r20123
This will allow more error checking, resilient slicing, and occasionally
other useful capabilities.
Step 1 of <rdar://problem/11940897>
Swift SVN r20036
