When using SwiftSyntax as a standalone tool, we invoke Swiftc
internally to get serialized syntax trees. This is not ideal for
several reasons: (1) we have to hard-code the relative path of swiftc
to invoke it; (2) we have to rely on standard input/output to pass the
tree across the process boundaries; and (3) we have to maintain two
different ways to get syntax tree (swiftc and sourcekitd).
This patch attempts to teach SwiftSyntax to use SourceKitd to get the
tree just like other clients. We first add a SourceKitd client library
written in Swift; and next teach SwiftSyntax to adopt this SourceKitd
client-side library. For platforms other than MacOS, we still use Swiftc
to get syntax trees. This client library also allows us to add
SourceKitd tests in Swift.
This patch also re-enables several flaky tests.
Other changes:
1) Minimize unified versus build-script build differences.
2) Stop trying to make runtime variables have "protected" visibility.
This combination is meaningless and lld rightly complains.
Finally, this blog post is worth reading:
http://www.airs.com/blog/archives/307
This makes it easier to read and see what is going on. This made it
easier to see what parameters were being passed when debugging the
windows cross-compilation dependencies.
This change leaves in place the use of -m*-version-min options, but
fixes the -target options to match. We can eventually remove the use of
the -m*-version-min options after everyone has moved to build with
versions of Clang that correctly handle the deployment version in the
-target option.
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`.
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.
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.
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.
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.
