'arch' and 'os' build configurations with valid identifiers as
arguments, but which are unknown to the compiler, will cause the
compiler to silently skip over that code as it has an inactive clause.
Emit a diagnostic, but not an error so as not to inadvertantly break
code that may be in a compiler without knowledge of a particular
operating system or architecture.
rdar://problem/22052176
Swift SVN r32219
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
Clang does this in the driver. Why not Swift? Because (a) this is an
implementation detail that really only affects IRGen, and even then
somewhat incorrectly, and (b) Swift has a good handful of clients that
don't go through the driver to create an ASTContext (specifically, LLDB,
along with many of our testing tools).
rdar://problem/19779274
Swift SVN r25909
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
