Extract the ExternalProject handling for libdispatch needed to build
SourceKit on Linux into a separate CMake list. This will allow us to
pull in a dependency on Foundation as well to allow building SwiftSyntax
on Linux which requires Foundation. Foundation has a dependency on
libdispatch requiring that the external project handling is centralised.
* Update std lib to Swift 5.0
* Disable Unicode.* warnings for now
* Slow path to resiliently handle the case where an unknown rounding rule is passed
* Remove resilience from Encoding/DecodingError (which should only happen on slow paths anyway)
* internal typealiases now need @usableFromInline
* Force inlining on Array._owner.get
When cross-compiling or specifying a custom sysroot and desiring a
hermetic build, many CMake toolchain files will have a custom
CMAKE_FIND_ROOT_PATH and set the CMAKE_FIND_ROOT_PATH_MODE_* variables
to ONLY, meaning packages will only be searched for in the rerooted
directories. We don't want this rerooting to happen when searching for
the LLVM and clang packages though, since we're specifying our search
paths explicitly and excluding search paths from the system, and we
don't want those explicit search paths to be rerooted.
It's standard to set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER instead
of ONLY, since you usually want programs to be found for the build
system and not the host system, so the change for the llvm-config search
is not technically required. It doesn't hurt for consistency though, and
I can envision some scenarios in which it might come in handy.
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.
