the ARC optimizer does not handle loops well, and so can get blocked by
the presence of a loop over the range. Therefore, add a single-element
check for the common case where we're not slicing.
Swift SVN r23502
That this code is dead implies we are throwing away the knowledge that
we have a native buffer whenever we downcast an array. That'll be fixed
when the array buffer simplification goes in.
Swift SVN r23350
We're still casting down, but only to the common base of all native
array buffers. Given that native buffers might turn out to be the empty
array buffer, this eliminates some evil type punning.
Swift SVN r23187
Again there is a loop that blocks retain/release matching.
The ARC optimizer is conservative and currently stops at loops.
This will get exposed by Dave's array patches.
rdar://18777237
Swift SVN r23134
Creating a range creates overflow checks, since we don't do anything with the
range in the case of value types these checks were truly superflous, and not
always cleaned up by llvm.
rdar://18777237
Swift SVN r23132
Exposing the raw baseAddress without lifetime control is error-prone.
Began to strip actual uses of baseAddress from specific models of
_ArrayBufferType, too.
Swift SVN r22950
It was doing an unsafeBitCast and possibly not managing lifetimes;
replace it with more-typesafe and memory-safe calls where possible.
Swift SVN r22779
Buffer identity is only used by tests. The switch to an identity
representation that accounts for the buffer length was actually
incorrect for the way many tests used it.
Swift SVN r22771
Fixes rdar://problem/18646425
Running the test uncovered avoidable inefficiencies in Array copying, so
dispatch of _copyToNativeArrayBuffer was revamped. It's reasonable to
expect some speedups from this.
Also, the internal Array API requestNativeBuffer was highly error prone
when the source was a Slice, because it could return an array buffer
that represented more than the entire slice. That capability was
probably used for optimization once, but is no longer, and the error
prone API probably caused bugs, so it was reformed.
Swift SVN r22746
NFC, and no significant performance change expected. This is part one
of a move to eliminate nil checks from the array implementation.
Swift SVN r22526
NFC, and no significant performance change expected. This is part one
of a move to eliminate nil checks from the array implementation.
Swift SVN r22495
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
This should allow us to better optimize repeated push/pop benchmarks.
I didn't notice a performance change at the time I did this. I'm just
putting it in as a hopefully obvious drive-by fix.
Swift SVN r21429
The syntax being reverted added busywork and noise to the common case
where you want to say "I have the right address, but the wrong type,"
without adding any real safety.
Also it eliminated the ability to write UnsafePointer<T>(otherPointer),
without adding ".self" to T. Overall, it was not a win.
This reverts commits r21324 and r21342
Swift SVN r21424
Previously, it was possible to write Unsafe[Mutable]Pointer(x) and have
Swift deduce the pointee type based on context. Since reinterpreting
memory is a fundamentally type-unsafe operation, it's better to be
explicit about conversions from Unsafe[Mutable]Pointer<T> to
Unsafe[Mutable]Pointer<U>. This change is consistent with the move from
reinterpretCast(x) to unsafeBitCast(x, T.self).
Also, we've encoded the operations of explicitly adding or removing
mutability as properties, so that adding mutability can be separated
from wild reinterpretCast'ing, a much more severe form of unsafety.
Swift SVN r21324
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
