This sanitizer adds MTE (memory tagging extension) checks to stack
variable accesses. Enablement simply requires setting an attribute on
function definitions, and the instrumentation is added by LLVM.
The corresponding swift-driver change is at:
https://github.com/swiftlang/swift-driver/pull/2016.
rdar://161721201
Replace env PATH manipulation with Swift driver's -tools-directory flag
to specify location of fake linker.
This seems to work with lit's internal shell, though I'm not 100% certain
it's the right approach.
This command-line option hasn't been Objective-C specific ever, really.
Make the language-independent spelling the primary one to make that
more obvious.
If a `.swiftinterface` file does not include an explicit `-language-mode`
option (or its predecessor `swift-version`) and needs to be built as a
dependency of a client compilation, then the invocation to build the module
from interface would end up inheriting the language mode that the client code
is built with. This can result in spurious type checking diagnostics or even
mis-compilation. To ensure that a module interface is always built using the
language mode that its source code was originally built with, require an
explicit `-language-mode` option when emitting swiftinterface files.
Resolves rdar://145168219.
Remarks emitted by LLVM use the mangled function name. Be consistent
with LLVM when serializing SIL remarks, so external tools can properly
filter for all remarks attributed to a certain function.
It is a maintenance burden and having the legacy driver exist in a simplified state reduces the possibility of things going wrong and hitting old bugs.
To allow tooling to analyze use of language mode and experimental/upcoming
features, add that information to the `.SWIFT_TRACE` file.
Resolves rdar://152673681.
This is the C++ driver counterpart to a change that landed in the Swift
driver a while ago to use the clang-linker to determine what the default
linker is. This is to avoid hard-coding gold, which is deprecated and
not available on some newer Linux distributions. The challenge is that
these newer Linux distributions don't already have Swift so we have to
use the old C++ driver implementation.
Use the `clang::TargetInfo` to query the target pointer size for the
given triple. This is meant to enable us to properly determine
`CMAKE_SIZEOF_VOID_P`.
Unified builds of compiler-rt together with LLVM failed for the Android SDKs. It got too complicated to redirect the way LLVM would configure the nested build-trees. Standalone builds slightly increase build time, but they turned out much simpler and we end up with less duplication of definitions.
When running the tests with a toolchain built with the "early swift
driver", we would incorrectly process the command line, losing the empty
string argument to `-sdk` which would then incorrectly process the
remainder of the command line. This allows most of the remaining tests
to pass with the early swift driver on Windows (assuming that the paths
are adjusted properly).
When enabling the early swift driver on Windows, these tests need to be
adjusted for the new driver name that is reported. Add an additional
spelling for the driver to accommodate that for the testsuite.
The legacy driver is still used to build the compiler on Windows, so we need it
to handle these new flags correctly in order to adopt them in the stdlib.
Add a new filetype for this mode option: "Raw LLVM IR". When the mode
option is emit-irgen, the new filetype will be the output kind;
conversely when determining the mode option to use, if the output kind
is the new filetype, the mode option will be emit-irgen.
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
This flag was added back in 2020, but it didn't function properly, since a lot of other code in the compiler assumed the platform-default C++ stdlib until recently (https://github.com/swiftlang/swift/pull/75589).
The recommended way to use a non-default C++ stdlib in Swift now is to pass `-Xcc -stdlib=xyz` argument to the compiler.
This change removes the `-experimental-cxx-stdlib` flag.
