This change includes a number of simplifications that allow us to
eliminate the type checker hack that specifically tries
AssertString. Doing so provides a 25% speedup in the
test/stdlib/ArrayNew.swift test (which is type-checker bound).
The specific simplifications here:
- User-level
assert/precondition/preconditionalFailure/assertionFailer/fatalError
always take an autoclosure producing a String, eliminating the need
for the StaticString/AssertString dance.
- Standard-library internal _precondition/_sanityCheck/etc. always
take a StaticString. When we want to improve the diagnostics in the
standard library, we can provide a separate overload or
differently-named function.
- Remove AssertString, AssertStringType, StaticStringType, which are
no longer used or needed
- Remove the AssertString hack from the compiler
- Remove the "BooleanType" overloads of these functions, because
their usefuless left when we stopped making optional types conform
to BooleanType (sorry, should have been a separate patch).
Swift SVN r22139
The initializer requirement is causing too much exponential behavior
in the constraint solver. We'll have to address that
first. Re-instating this change is tracked by rdar://problem/18381811.
Swift SVN r22080
With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091.
Swift SVN r22078
over String.extend
Performance testsuite changes over 2% are as follows. A lot of tests unrelated
to String have been affected because of measurement noise and because strings
are used in result verification.
Ary3 4.8%
CaptureProp 10.3%
Dictionary -4.0%
EditDistance 2.8%
Forest -4.0%
Hash 8.6%
InsertionSort 6.7%
Life -2.3%
MatMul 2.6%
NestedLoop 3.9%
PopFrontArray 2.9%
PrimeNum 3.6%
Prims 2.2%
SmallPT -2.1%
TwoSum 4.1%
Swift SVN r21629
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
I wish I knew how to code a regression test for this, but sadly I don't.
The only performance differences with magnitude > 7% show up in
-Ounchecked, and most of these look suspiciously like noise due to the
irrelevance of generic string append. The only one I'd be remotely
concerned about is StrToInt, but it doesn't make any sense that it
should have gotten slower, so I think that's noise too.
Ackermann: -14.3%
Fibonacci: 33.3%
ImageProc: 9.0%
Phonebook: -7.1%
QuickSort: 15.6%
StrToInt: -14.3%
Swift SVN r21236
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
1. Remove incorrect @readonly semantics on two functions.
2. Overload toString for some of the popular types and add readonly semantics so that we can optimize them away.
Swift SVN r21045
Symmetry with what we did for Arrays says that Strings shoudl only
concatenate to Strings using "+". We have append() for adding single
characters.
Swift SVN r20997
_preconditionFailure()s. Some of these checks are clearly redundant (for
example, the check of array subscript), but since we have no tests for
these traps (and reflection is not fast in general), I prefer to keep this
transformation as straightforward as possible.
Swift SVN r20971
On -Ounchecked we are now able to zap this expression (from Richards):
UnicodeScalar(UInt32(2)+"0".value)
However, on -O we still check for overflow and actually need to construct the string.
Swift SVN r20856
This accelerates Richards by 4X because we don't need to construct debug strings such as:
debug("TCB \(tcb!.id) state \(tcb!.state.bits)")
Swift SVN r20853
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
is performed according to the deterministic Unicode collation algorithm,
which allows us to use the hash of the NFD form.
rdar://17498444
Swift SVN r20543
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20518
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20495
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
This will allow more error checking, resilient slicing, and occasionally
other useful capabilities.
Step 1 of <rdar://problem/11940897>
Swift SVN r20036
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
