Rather than use `fprintf` for the error handling path use the platform
specific error handling systems (`asl_log`, `__android_log_printf`) if
available. The standard file streams are not available on all platforms
(e.g. Android).
Rather than build multiple copies of LLVMSupport (4x!) build it one and
merge it into the various targets. This would ideally not be needed to
be named explicitly everywhere, but that requires using `add_library`
rather than `add_swift_target_library`.
Reduce LLVMSupport to the subset required for the runtime. This reduces
the TCB and the overheads of the runtime. The inline namespace's
preservation ensures that ODR violations do not occur.
This adds the `__swift::__runtime` inline namespace to the LLVMSupport
interfaces. This avoids an ODR violation when LLVM and Swift are in the
same address space. It also will aid in the process of pruning the
LLVMSupport library by ensuring that accidental leakage of the llvm
namespace does not allow us to remove symbols which we rely on.
This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
