It was doing an unsafeBitCast and possibly not managing lifetimes;
replace it with more-typesafe and memory-safe calls where possible.
Swift SVN r22779
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
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
Expose any, all on Array and all the Lazy sequence adapters. Make the
'contains' algorithm that takes a predecate unavailable in favor of
'any', which does the same thing.
Fixes <rdar://problem/18190149> [algorithm] `contains` syntax is ambiguous
Swift SVN r21810
CaptureProp , -21.8%
HeapSort , 12.7%
ImageProc , -25.6%
StrCat , 92.6%
StrComplexWalk , 11.1%
StrToInt , 16.6%
StringInterpolation , 21.6%
Regression in CaptureProp is due to some interference of the harness. When the
code is extracted into a separate file, there is no difference.
Regression in ImageProc is caused by unconditional construction of a string for
CheckResults()
rdar://18119872
Swift SVN r21535
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
As I was reducing a test case for a typechecker bug, I ended up
commenting out important test code in the regression suite. This
restores it (and makes it work).
Swift SVN r20925
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
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
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
As before, there may be more things marked @public than we actually want
public. Judicious use of the frontend option -disable-access-control may
help reduce the public surface area of the stdlib.
Swift SVN r19353
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
In UTF-8 decoder:
- implement U+FFFD insertion according to the recommendation given in the
Unicode spec. This required changing the decoder to become stateful, which
significantly increased complexity due to the need to maintain an internal
buffer.
- reject invalid code unit sequences properly instead of crashing rdar://16767868
- reject overlong sequences rdar://16767911
In stdlib:
- change APIs that assume that UTF decoding can never fail to account for
possibility of errors
- fix a bug in UnicodeScalarView that could cause a crash during backward
iteration if U+8000 is present in the string
- allow noncharacters in UnicodeScalar. They are explicitly allowed in the
definition of "Unicode scalar" in the specification. Disallowing noncharacters
in UnicodeScalar prevents actually using these scalar values as internal
special values during string processing, which is exactly the reason why they
are reserved in the first place.
- fix a crash in String.fromCString() that could happen if it was passed a null
pointer
In Lexer:
- allow noncharacters in string literals. These Unicode scalar values are not
allowed to be exchanged externally, but it is totally reasonable to have them
in literals as long as they don't escape the program. For example, using
U+FFFF as a delimiter and then calling str.split("\uffff") is completely
reasonable.
This is a lot of changes in a single commit; the primary reason why they are
lumped together is the need to change stdlib APIs to account for the
possibility of UTF decoding failure, and this has long-reaching effects
throughout stdlib where these APIs are used.
Swift SVN r19045
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
Will be useful in optimizing bulk array mutations such as sort()
Also stopped making UnsafeArray a generator; in general making a
collection a generator seems somewhat muddled and dangerous, especially
when it comes to adapters that may have reference semantics.
Swift SVN r18924
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
conform to LogicValue.
This approach was taken to keep _isNull because I first tried
to just use comparisons to nil instead of isNull(). Apparently
that led to some circular definitions, so it was easier to just
stage it this way.
Swift SVN r18301
