That commit made a protocol public. The protocol was underscored but
some of its APIs were not, and those became unintentionally publicly
visible. This commit corrects that problem. Since Builtin.RawPointer
properties were being renamed from "value" to "_rawValue" for clarity,
COpaquePointer got that treatment too, even though it wasn't strictly
necessary, for consistency.
Swift SVN r22252
240 undocumented public non-operator APIs remain in core
Note: previous estimates were wrong because my regex was broken. The
previous commit, for example, had 260 undocumented APIs.
Swift SVN r22234
A collection whose count changes between traversals could cause a memory
safety problem, as we would measure the collection in one pass and
assume that it was the same length when actually initializing array
elements. Fix that by always using the initial measurement, which
corresponds exactly to allocated memory. If the collection wants to
trap because we've gone past its new bounds, that's fine. If it
doesn't, at least we haven't done anything unsafe.
Swift SVN r22152
Replaced the general implementation (which works for all array types) to the obvious and trivial implementation for Array.
This speeds up array literal initialization by about 2x.
Swift SVN r21626
The buffer argument of _arrayReplace was a protocol and it forced
all of the calls to that member to be virtually dispatched and generic.
This boosts DeltaBlue by 2X.
Swift SVN r21405
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
Array literal construction currently goes through an expensive dance;
Adding _allocateUninitialized will allow SILGen to do something much
smarter.
Swift SVN r20448
This way, array optimization can see initialization as a copy of the
whole array value into a local variable, regardless of whether it's
from a factory method or Array initializer.
I'm making an assumption that when we return an Array by value, we
can't have an alias of the array buffer without retaining it.
Swift SVN r20444
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
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
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
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
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
