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.
This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
Remove the flag being specified in multiple locations unnecessarily.
The flags flow downwards to all the subdirectories. Use that to apply
the C/C++ flags from the root of the runtime repository.
The “ios-like” build flavor is used to build modules that do not exist on macOS for Mac Catalyst. Even though they are built for the “OSX” SDK, they need to have a “MACCATALYST”-style module triple; unfortunately, the transition to naming swiftmodules by module triple in #31170 did not handle this edge case correctly.
This commit handles that by piggybacking on a similar special case used to change the lib/swift subdirectory.
The standard library (and other Swift modules built by our CMake build system)
has been building module files with an architecture only (e.g., x86_64.swiftmodule)
rather than a proper module triple (x86_86-apple-macosx10.15,
x86_64-apple-ios13.0-simulator, etc.), unlike every other build
system. There are hacks in the compiler and other tools to cope with
this unnecessary build difference. Fix the module file names so we'll
be able to remove the hacks later.
Fixes rdar://problem/49071536.
