Create a list that makes it easy to see and add options to the CMake
macro when building. This makes the `cmake_parse_arguments` call much
more legible by adhering to the CMake recommendations. NFC.
- Re-enable the use of folders with the USE_FOLDER setting. This got
lost a while ago when we stopped including LLVM's top-level
CMakeLists.txt.
- Put a bunch of new targets into folders.
Should not affect the built product and definitely shouldn't affect
anyone not building with Xcode (or MSVC, I guess).
Newer SDKs have the ability to disable the static RTTI usage as well as
the dynamic. We had to enable the use of static RTTI previously for the
use of `std::function`. Disable the static RTTI if possible.
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
The /GR- emulation is needed to support building on Windows.
std::function in Microsoft's C++ runtime requires the use of `typeid`.
We do not want to emit RTTI data. `-frtti -fno-rtti-data` allows the
use of the `typeid` and `dynamic_cast` behaviours but will not emit the
RTTI data. With this change, it is possible to build the Windows
runtime once again.
When building with asserts or debug information, don't disable leaf
frame pointers because some debugging/analysis tools have buggy or
nonexistent support for DWARF-style backtraces.
This is needed to support cross-compilation on targets which do not
support FAT binaries (i.e. non-MachO targets). The primary user of this
functionality right now is Windows, but this support is needed for Linux
and android as well.
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.
