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.
In order to substitute the path into the VFS overlay, we need to escape
the paths. Instead, opt on the CMake behaviour of
`get_filename_component` providing the canonicalised path with forward
slashes rather than backslashes. This allows the overlay to be used on
Windows as well as Linux.
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.
Set the deployment target to an empty string for non-Darwin platforms
so that it is safe to append to the target triple without guarding it
with a check for Darwin.
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`.
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.
