Also, hide an initializer on String.Index that was unintentionally
public/visible by giving it an underscored keyword argument.
Testing comes next.
Swift SVN r24069
Also clean unused detritus and anacrhonisms from testing code.
Tests for the currently-implemented conversions were incomplete, but are
now done.
Swift SVN r24068
This is just a basic implementation of each, with some questions
lingering about whether to do unicode normalization (and if so how),
but it gets things going.
Swift SVN r23572
It used to be a public enum, which unnecessarily exposed structure that
was intended to be private implementation detail. This change also has
the benefit that converting a String to a Character will avoid
allocating memory in many more cases.
Swift SVN r22629
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
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
With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091. r22176 eliminated the performance penalty
that prevented this change from sticking earlier.
Swift SVN r22177
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
