The Windows SDK proides kernel32.Lib which on case sensitive file systems will
fail (due to the capital L in the extension). Workaround that by creating
symbolic links to handle this. This mirrors the technique used in LLVM.
Extract the C++ header search path from the system header search path. This is
needed to ensure that we do not push the C++ headers into the swift compiler
search path. The reason here is that when building the module, we would attempt
to include the C++ headers, which we cannot do since the ClangImporter in swift
explicitly sets the langugage to C. This would break the stdlib build for
android.
When cross-compiling the Windows standard library in release mode, we
would get undefined symbols due to LLVM invoking
`add_definitions(-D_DEBUG)`. This would change the behaviour of certain
functions from MSVCRT resulting in undefined symbols. Scrub out the
unwanted `-D_DEBUG`.
Merge two cases into a single case rather than keeping them separate.
Additionally check the condition early rather than perform the action
and then revert it. NFC.
Hoist out the some of the architecture independent variables outside of
the inner loop. This should simplify the logic for the function and
improve generation times. (NFC)
This corrects the casing which would previously not match.
Unfortunately, the `MATCHES` operator also does not handle the case
insensitivity properly. This enables building just the standard library
on Linux for Windows.
This just cleans up the invocation generation for android to avoid passing in
`--sysroot=` twice to the driver with the same value. This has no impact, but
cleans up the command line so it is easier to see what is going on.
When building for Windows on Windows using Visual Studio, we would attempt to
pass the clang specific flags to cl. It would then attempt to treat the overlay
definition as an input and fail. Although this shouldn't be needed on Windows,
it keeps the builds with clang similar across Linux and Windows.
Add the `-warn-implicit-overrides` flag when building the standard library
and overlays, so that each protocol member that overrides a member of an
inherited protocol will produce a warning unless annotated with either
‘override’ or ‘@_nonoverride’.
An annotation of `override` will mean that the overriding requirement will be treated identically to the overridden declaration. If for some reason a concrete type’s conformance to the inheriting protocol provides a different witness for the overriding requirement than the conformance to the inherited protocol’s witness for the overridden requirement, the witness for the inheriting (more-specialized) protocol will be ignored. A protocol requirement marked ‘override’ only makes sense when the declaration is needed to help associated type inference, which is why the ‘override’ annotations correlate so closely with ABI FIXMEs.
An annotation of `@_nonoverride` means that the two protocol requirements will be treated independently, and may be bound to different witnesses. Use `@_nonoverride` when we might need different witnesses, e.g., because the semantics of the potentially-overriding declaration differ from that of the potentially-overridden declaration. `BidirectionalCollection.index(_:offsetBy:)` is the most obvious example, because the `BidirectionalCollection` ’s version of `index(_:offsetBy:)` allows negative indices. `RandomAccessCollection` ’s version is also marked `@_nonoverride` because it is required to be asymptotically faster than the `Collection` or `BidirectionalCollection` versions.
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.
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.
- 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 /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.
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.
