The Windows ARM SDK is incomplete. However, the headers are complete
enough to support building the runtime. Add the necessary definitions
to permit the stdlib to be built.
I recently broke the out of tree build by mistake [its fixed now ; )]. This
inspired me to make it easy to test this behavior by adding support to
build-script/cmake/etc for running an external benchmark build via
AddExternalProjects.
Now I can just call build-script with --build-external-benchmarks and thats it!
It should just work! It already helped me to avoid breaking the external build
twice!
I hope that eventually we get this on a bot to make sure it keeps working [or
even added to the smoke tests ; )].
*NOTE* This is disabled by default so it will not affect normal builds.
*NOTE* This just builds the external benchmarks. There is an rpath issue that
prevents you from running them (the benchmarks have the rpath set as if they are
next to the stdlib, but they are not. This can be fixed in a few different ways,
but I do not have time to finish implementing it = (. But this commit is a good
first step and at least detects build errors.
Rather than use the `INCLUDE` and `LIB` environment variables to build
the Windows code, use the `UniversalCRTSdkDir`, `UCRTVersion`, and
`VCToolsInstallDir` variables. Using these we can compute the right set
of include directories and library search paths for the various
architectures. This will enable us to build multiple variants of the
Windows stdlib at the same time.
Additionally, rather than relying on the magic environment variables to
be processed by the driver, pass them explicitly to the driver through
the build system. This also is needed to allow parallel builds of
various architecture variants of the stdlib on Windows.
When building for Windows, when using `offsetof` in a C++ context, we
would use a `reinterpret_cast`, which is not permissible in the context
of a `constexpr` statement which we do use. Use a CRT specific macro to
use the `__builtin_offsetof` version of the implementation. Repairs the
Windows stdlib build with the new include path handling.
The file system layout on exherbo is different from most other Linux
distributions. Add an additional ignored case for the include paths for
when cross-compiling the stdlib to additional targets.
The CMake function `get_effective_platform_for_triple` appears to only
be used in one location: from within `escape_path_for_xcode`.
The `get_effective_platform_for_triple` function's only purpose appears to be
to check whether `SWIFT_HOST_TRIPLE` contains the string "macos", and if not,
it emits an error.
However, because on macOS hosts the build-script-impl is responsible
for setting the `SWIFT_HOST_TRIPLE` variable, when `cmake -G Xcode` is invoked
directly to configure the Swift project, this variable is unset, and so
`get_effective_platform_for_triple` emits an error.
I considered two solutions:
1. Have `swift/CMakeLists.txt` set a default `SWIFT_HOST_TRIPLE`, as it
does for Linux. This would prevent `get_effective_platform_for_triple`
from emitting an error.
2. Remove `get_effective_platform_for_triple` altogether.
I chose (2) here. `get_effective_platform_for_triple` doesn't appear to
do anything besides restrict the host platform arbitrarily. If users
are somehow able to configure the project using `cmake -G Xcode` on
Linux, shouldn't the Swift's CMake allow them to do so?
Test plan:
1. Configure and build using Xcode and an in-tree Swift checkout.
2. Configure and build using `utils/build-script --xcode`.
* Create Swift libSyntax API
This patch is an initial implementation of the Swift libSyntax API. It
aims to provide all features of the C++ API but exposed to Swift.
It currently resides in SwiftExperimental and will likely exist in a
molten state for a while.
* Only build SwiftSyntax on macOS
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
LLVM-style projects like Swift make heavy use of switch statements and
therefore -Werror=switch is very useful during feature development. That
being said, if asserts are disabled, then you're probably not actively
hacking on the project and -Werror (or warnings in general) aren't
helpful.
* Generate libSyntax API
This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
Swift doesn't produce its own tablegen and by faking out the LLVM CMake infrastructure into thinking it does all of LLVM's build cross compilation support breaks.
Cygwin is considered a distinct target with a distinct ABI, environment
conditions, and data types. Though the goal of the project is
native Windows integration with UNIX-likes, that is not compatible with
the idea that the platform can be ignored as Win-like enough to have the
existing os(Windows) condition apply.
Introduce a new function `add_swift_tool_symlink`. Use this instead of the
`add_llvm_tool_symlink` and `install_in_swift_component`. This mimics the
behaviour in clang as well as the general pattern of renaming the functions from
the LLVM build infrastructure.
With the change in LLVM r305142, CMake will fail if SWIFT_TABLEGEN_TARGET
is not set. When cross-compiling, it could be set differently than
SWIFT_TABLEGEN_EXE but it does not look like Swift supports that yet. For
now, just set it to the same value as SWIFT_TABLEGEN_EXE.
* Revert "[strip -ST] Disable runtime stack trace dumping on Darwin when asserts are disabled."
This reverts commit 6bc28ff1c9.
* Bring back important fixes from the revert of 6bc28ff1c9.
* Change swift::swift_reportError to only print the backtrace in assert builds (swift::warning prints backtrace always).
This commit disables runtime stack trace dumping via dladdr on Darwin when
asserts are disabled.
This stack trace dumping was added as a way to improve the ability to debug the
compiler for compiler developers. This is all well and good but having such a
feature always enabled prevents us from reducing the size of the swift standard
library by eliminating the swift nlist.
rdar://31372220
The warnings about deprecated @objc inference in Swift 3 mode can be a
bit annoying; and are mostly relevant to the migration workflow. Make
the warning emission a three-state switch:
* None (the default): don't warn about these issues.
* Minimal (-warn-swift3-objc-inference-minimal): warn about direct
uses of @objc entrypoints and provide "@objc" Fix-Its for them.
* Complete (-warn-swift3-objc-inference-complete): warn about all
cases where Swift 3 infers @objc but Swift 4 will not.
Fixes rdar://problem/31922278.
