PR #14306 fixed the problem in https://bugs.swift.org/browse/SR-6878 but
included a comment about mysterious behavior on macOS. I did some
investigation and found that Clang assumes that Darwin platforms use
a different name for LLD. My impression is that LLD is not yet ready for
prime time on Darwin, so leaving it disabled for Apple platforms seems
like the right thing for now. This just updates the comments to explain
what will need to change whenever someone wants to reenable it.
rdar://problem/37053028
ndk14 introduced "unified headers" which merged the headers for all
different API versions into one directory which effectively split the
"SWIFT_SDK_ANDROID_ARCH_${ARCH}_PATH" into two different directories.
Add include and library specific paths to various compilation and link
invocations across the Swift project to account for this change. Remove
some broken sysroot/sdk specific settings.
Report the ICU I18N and UC include paths and the library path. This
makes it obvious when the variable is not defined and more importantly
makes it easier to see what the paths are being used particularly when
cross-compiling for multiple architectures.
This also fixes several issues where attribute arguments could not be
parsed as a TokenList since some of its arguments already had structure
and were not tokens
`-ivfsoverlay` is no longer passed through to the driver with
`clang-cl`. Explicitly mark it as a clang option to ensure that the
option is handled properly. This repairs the build on Windows.
StdlibUnittest uses gyb to avoid duplicating many source-context
arguments. However, this means that any test that wishes to add new
expect helpers has to also be gybbed. Given that this structure hasn't
changed in years, and we should have a real language support
eventually, de-gyb it.
The `-sdk` parameter to the swift compiler causes problems when
cross-compiling to Windows on Linux. Because the host follows the
traditional unix layout but the headers do not correspond to the target
environment, there are conflicting definitions and incorrect definitions
of basic types imported from C. Ensure that we do not pass the `-sdk`
parameter to allow correctly building the libraries for the target.
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.
General purpose cross compilation from host x to targets a,b,c will
require the ability to have multiple architectures passed to
`configure_sdk_unix`. Simply change the function to accept multiple
archs.
- 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 existing libSyntax infrastructure uses external python
dictionaries to share logic between C++ and Swift implementations.
This patch teaches trivia kinds to adapt to this infrastructure
as well.
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.
Make the quoted parameters more portable. This is needed in order to
support building swift on Windows. Simplify the declaration of the
flags and do a small formatting clean up. This ensures that the ninja
generation gets the command line invocation correct.
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.
This is a workaround for Visual Studio's link causing corruption with
incremental linking. The markers for the metadata are padded out
incorrectly, resulting in load time failures. With this, it is possible
to link with link and use the generated binaries on Windows x86_64.
