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.
- 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
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.
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 two invocations here both had a single parameter passed to it.
Replace it with `add_dependencies` which already actually supports
multiple dependencies specified. Sink the custom wrapper into the
usage location in `AddSwiftStdlib.cmake`.
New files were added in #30875 which did not include os(OpenBSD), so add
this.
add_swift_target_library in AddSwiftStdlib subsequently required
modification. _add_target_variant_link_flags likely needs modification as
well, but this is better suited to a separate PR.
This is a purely code motion change. It moves the functions that are
specific to `SwiftSource.cmake` into `SwiftSource.cmake`. Target
functions are moved to `stdlib/cmake/modules/AddSwiftStdlib.cmake`.
