Since the NDK removes the platforms/ and sysroot/ directories in the latest NDK
22, switch to the unified sysroot in toolchains/llvm/ and take advantage of a
bunch of simplification that's now possible.
There's no reason to use -m${platform}-version-min as of clang-11/Xcode 11. Clang is now smart enough to parse -target and provide Apple's ld with the appropriate -platform_version argument string.
Credit for the cmake fix here goes to Saleem Abdulrasool.
The substantive fix is embarrassing; I didn't pay close attention
to the intrinsic's argument order and just assumed that the first
argument for the replacement value was the low half (the part
you'd find at index 0 if it were an array), but in fact it's the
high half (the part you'd find at index 1).
I also change the code to be much more reinterpret_casty, which
isolates the type-punning mostly "within" the intrinsic, and
which seems to match how other code uses it.
... and other products as well.
Before this change, the dependency was enforced only for stdlib object
files -- since according to the Ninja dependency graph other libraries
can be scheduled as soon as the swiftmodules are ready, there is a
chance that we attempt to build those before legacy layours are copied.
Addresses rdar://71559791
We already get warnings from clang at compile time. For cases where we silence those, with SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_BEGIN, these warnings are just noise.
rdar://problem/70445131
This fixes issues when building Swift with concurrency enabled by default. See rdar://71045297
If some of our overlays need to use the concurrency API, they can manually import _Concurrency.
This matches the behaviour for emitting macCatalyst swiftmodules and should avoid preferring dependencies from the SDK instead of just built ones.
Addresses rdar://70682224
This changes the install layout to be similar across Darwin and
non-Darwin platforms. This will enable simplifying the user experience,
build infrastructure, and the driver as the SDK layout converges towards
a single layout on all the platforms.
- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
Build swift-frontend as the primary Swift binary, and have
swift/swiftc/etc. symlink over to it. This is a step toward allowing
swift-driver to replace the swift and swiftc binaries.
Since libDemangling is included in the Swift standard library,
ODR violations can occur on platforms that allow statically
linking stdlib if Swift code is linked with other compiler
libraries that also transitively pull in libDemangling, and if
the stdlib version and compiler version do not match exactly
(even down to commit drift between releases). This lets the
runtime conditionally segregate its copies of the libDemangling
symbols from those in the compiler using an inline namespace
without affecting usage throughout source.
The host platform should be using `CMAKE_SYSTEM_NAME STREQUAL Darwin`.
However, we currently drive the host side of the compilation against
custom variables. This makes the migration simpler by ensuring that the
entire file uses the same pattern.
Since `is_darwin_based_sdk` is now used only in the standard library
build, sink it to the standard library build.
Also remove some ancient logic to detect and ignore requests to use LLD.
If people want to explicitly use LLD, they probably have a reason and we
shouldn't second guess them.
Windows had moved to C++14 much earlier than the rest of Swift. This
was required in order to deal with the Windows SDK headers. Now that
the project has fully moved to C++14, remove the unnecessary settings
for Windows.
