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
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
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
...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
The facility we had before was not very usable in core elements of the
standard library because it relied too much on those elements itself.
The result could be some spectacular infinite recursions and general
erosion of certainty, and was making development of Swift's String very
difficult.
In this commit we use extremely low-level primitives to avoid the recursion
problem. Also, because the purpose of all the older assertion functions
was unclear and there was a great deal of overlap in terms of
functionality, we clarify naming and consolidate functions.
As much as possible, the semantics of all existing tests in the face of
Asserts-enabled/-disabled build configuration changes has been
preserved, but the new naming makes it obvious in some cases that the
semantics may not have been well-chosen, which speaks well for the new
names. (**)
The two forms of "assert()" are completely enabled or
disabled--including evaluation of the condition--based on build
configuration. This follows the usual semantics from C, with the
differences being:
* No multiple evaluation badness from preprocessor macros, of course
* When a condition is supplied, assert accepts an optional message
* When no condition is supplied, fires unconditionally and requires a
message
The other functions are always enabled and only differ between build
configurations in how much information they attempt to deliver through
non-core-dump channels. When assertions are disabled and these
functions fire, they invoke a debugger trap, and do nothing else.
(**) It also opens some questions about policy. For example, should we
consider overflow and underflow to be securityChecks, as we do now, even
though they do not directly cause a memory safety issue? We could wait
for e.g. bounds checking on arrays to catch those problems before they
become memory safety issues, and gain a little speed in the regular
arithmetic path.
Swift SVN r12854
