We can finally get rid of -sil-serialize-all when building the standard library! This option will be completely eliminated in the future commits.
Instead of serializing just everything as we did before, we now serialize only functions annotated with @_inlineable. This way we can selectively control what needs to be available to the clients. This is an important step towards building a resilient standard library.
While this is a huge change for the serialization of the stdlib, it should be virtually invisible to the clients. For example, there are no noticeable performance regressions on any of the benchmarks.
This enables us to distinguish in between builds which are triggered by a
subcmake call from the main swift cmake file and one from a user who is trying
to compile the swift benchmark suite against a misc swift installation/use the
ninja file by hand.
When passing the linker search path options to the driver, ensure that
we quote the argument. We would previously incorrectly split the
arguments that were passed to the driver if there were spaces. This
would manifest as link failures on Linux when cross-compiling to
Windows.
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).
