/// \brief An extremely simple string designed to represent something
/// "statically knowable".

// Implementation Note: Because StaticString is used in the
// implementation of assert() and fatal(), we keep it extremely close
// to the bare metal.  In particular, because we use only Builtin
// types, we are guaranteed that no assertions are involved in its
// construction.  This feature is crucial for preventing infinite
// recursion even in non-asserting cases.
struct StaticString : BuiltinStringLiteralConvertible, StringLiteralConvertible {
  var start: Builtin.RawPointer
  var byteCount: Builtin.Word
  var isASCII: Builtin.Int1

  init() {
    self = ""
  }
  
  init(start: Builtin.RawPointer, byteCount: Builtin.Word, isASCII: Builtin.Int1) {
    self.start = start
    self.byteCount = byteCount
    self.isASCII = isASCII
  }

  // FIXME: this is a hackaround for <rdar://problem/15888736> fatal()
  // can't take a StaticString?!
  init(nulTerminated: CString) {
    self.start = nulTerminated._bytesPtr.value
    self.byteCount = _strlen(nulTerminated).value
    self.isASCII = false.value
  }
  
  type func _convertFromBuiltinStringLiteral(
    start: Builtin.RawPointer, byteCount: Builtin.Word, isASCII: Builtin.Int1
  ) -> StaticString {
    return StaticString(start: start, byteCount: byteCount, isASCII: isASCII)
  }
  
  type func convertFromStringLiteral(value: StaticString) -> StaticString {
    return value
  }
}

Implement a sane assert/fatal error check system
[stdlib] Implement a sane assert/fatal error check system

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
