The Windows SDK headers require C++14 or newer features. Visual Studio
is lax in enabling these features unlike clang. Explicitly upgrade to
the higher standard for the Windows cross-compilation.
Restructure the COFF metadata handling to use the linker section
grouping to emit section start/stop markers in the appropriate location.
This allows us to lookup the sections statically without having to the
walk the entire image structure.
Introduce a constructor for PE/COFF binaries. This will ensure that the
registration occurs for all modules appropriately. This should resolve
rdar://problem/19045112. The registration should occur prior to
`DllMain` being invoked from `DllMainCRTStartup`.
This change broke the Windows builds for all the variants. `-z defs` cannot be
used on all targets, particularly in environments where the stdlib is being
compiled for a foreign host. This needs to be handled more carefully as I
mentioned on the PR itself. In the mean time, revert it to get Windows building
again.
Restructure the ELF handling to be completely agnostic to the OS.
Rather than usng the loader to query the section information, use the
linker to construct linker tables and synthetic markers for the
beginning and of the table. Save off the values of these pointers and
pass them along through the constructor to the runtime for registration.
This removes the need for the begin/end objects. Remove the special
construction of the begin/end objects through the special assembly
constructs, preferring to do this in C with a bit of inline assembly to
ensure that the section is always allocated.
Remove the special handling for the various targets, the empty object
file can be linked on all the targets.
The new object file has no requirements on the ordering. It needs to
simply be injected into the link.
Name the replacement file `swiftrt.o` mirroring `crt.o` from libc. Merge
the constructor and the definition into a single object file.
This approach is generally more portable, overall simpler to implement,
and more robust.
Thanks to Orlando Bassotto for help analyzing some of the odd behaviours
when switching over.
The Windows SDK provides headers which have incorrect cases. The
incorrect cases are in the SDK headers as well. On case sensitive file
systems this causes build issues due to the incorrect name. Use the
clang VFS overlay to avoid the need for providing copies to the expected
cases. This improves the cross-compilation on Linux to Windows.
Windows ARM NT (the modern, non-Windows CE environment) is a pure thumb2
environment. The frontend does not canonicalise the target like in
clang. Ensure that we map the triple by hand to the desired target
triple.
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.
