Commit Graph

15 Commits

Author SHA1 Message Date
Dave Abrahams
1fb11d623b [stdlib] Remove _buffer requirement from ArrayType
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
2014-06-26 08:54:07 +00:00
Dave Abrahams
d1aa6fe2b8 [stdlib] Rename Array internals for clarity
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
2014-06-26 01:49:54 +00:00
Jordan Rose
cca27d02a0 Tag everything in the standard library with accessibility attributes.
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
2014-06-24 21:32:18 +00:00
Dave Abrahams
85533dd7d3 [stdlib] Restore Array value semantics
'nuff said.

Swift SVN r18923
2014-06-16 13:56:15 +00:00
Argyrios Kyrtzidis
b1914701e9 [stdlib] In ContiguousArrayBuffer<T>, vars 'storage' and 'base' where under the 'private' section
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
2014-05-25 04:31:13 +00:00
Doug Gregor
67ca1c9ea1 Implement the new casting syntaxes "as" and "as?".
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
  - The existing ConditionalCheckedCastExpr expression node now represents
"as?". 
  - A new ForcedCheckedCastExpr node represents "as" when it is a
  downcast.
  - CoerceExpr represents "as" when it is a coercion.
  - A new UnresolvedCheckedCastExpr node describes "as" before it has
  been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
  wasn't a strictly necessary change, but it helps us detangle what's
  going on.

There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
  - Custom errors when a forced downcast (as) is used as the operand
  of postfix '!' or '?', with Fix-Its to remove the '!' or make the
  downcast conditional (with as?), respectively.
  - A warning when a forced downcast is injected into an optional,
  with a suggestion to use a conditional downcast.
  - A new error when the postfix '!' is used for a contextual
  downcast, with a Fix-It to replace it with "as T" with the
  contextual type T.

Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift. 

Addresses <rdar://problem/17000058>


Swift SVN r18556
2014-05-22 06:15:29 +00:00
Dmitri Hrybenko
2fc5297171 stdlib/Slice: relax assertion to allow Slice<T> to be constructed from a native
empty buffer without storage

rdar://16971593 rdar://16388632


Swift SVN r18489
2014-05-21 11:01:55 +00:00
Ted Kremenek
16dea15a24 Hide CocoaArray ('_' to mark as private API).
Swift SVN r18302
2014-05-18 04:03:32 +00:00
Doug Gregor
bed81488c1 Revert r18232, r18220: we're not doing T* now.
Swift SVN r18250
2014-05-17 16:36:02 +00:00
Dave Abrahams
46388dd5e2 [stdlib] Unwrap some lines shrunken by T*
Concision FTW!

Swift SVN r18232
2014-05-17 00:27:43 +00:00
Doug Gregor
73f02d1a69 Switch a bunch of UnsafePointer<T>'s over to T*
Swift SVN r18220
2014-05-16 22:32:01 +00:00
Arnold Schwaighofer
da6d9152b6 Differentiate between user assertion and preconditions and the like
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
2014-05-16 20:49:54 +00:00
Dave Abrahams
b666651e3f [stdlib] Rename NativeArray => ContiguousArray
Per API review feedback.

Swift SVN r18140
2014-05-15 23:24:09 +00:00
Ted Kremenek
fad874708e Adjust test cases.
Swift SVN r17964
2014-05-12 22:01:52 +00:00
Dave Abrahams
004998e63e [stdlib] Move SliceBuffer into its own file
Swift SVN r15766
2014-04-02 02:47:34 +00:00