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
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
