assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
... unless we actually hit one of the confusing cases involving
multi-dimensional arrays (e.g., Int[]?[]), at which point one needs to
write parentheses <rdar://problem/16737035>.
Swift SVN r18181
This fixes a case where the Swift-variadic and C-varargs versions of
various initializers were superseding each other
<rdar://problem/16801456>.
It also uncovered some more cases where we weren't getting quite the
right semantics for factory-methods-as-initializers, which are also
fixed here.
Swift SVN r18010
The hack to get the LLVM build system to do what we want is to define a
custom build rule for "XYZ.o" and then add "XYZ" as a dummy source file
to the SOURCES variable, which the LLVM Makefile system uses. To make it
clear that something unusual is going on here, I've changed all existing
instances of this to use "XYZ.o" in SOURCES, rather than having that name
be derived from "XYZ.swift" or whatever.
The actual Swift source files go in SWIFT_SOURCES for the time being
(and possibly forever, since Swift sources will always be built together).
Swift SVN r11058
Since our build system isn't really set up to cope with
multi-sourcefile-modules, dump all Foundation support directly into
Foundation.swift
Swift SVN r11049
Because we're using a "brute-force" combination of conversion to
NSString and forwarding, this code will continue to work when String
is replaced by NewString. It may not be fast yet, but at least it
will flesh out the experience for Cocoa programmers
Swift SVN r11034
