- **Explanation**: Adding support for `swift-frontend -print-target-info -target wasm32-unknown-emscripten`, which is required before this triple is supported in `swiftc`.
- **Scope**: Limited to Emscripten Wasm support.
- **Issues**: rdar://175887675
- **Risk**: Very low due to limited scope.
- **Testing**: Added a new case to the lit test suite.
Default to use new swift-driver to run lit tests as legacy swift driver
is deprecated for a long time. The lit tests for legacy drivers are also
disable when running new swift-driver.
Tests that relies on legacy swift driver (for example, tests merge
module) can be enabled on conditions `legacy_swift_driver`. Fix and
split up some existing tests that relies on legacy driver.
This mirrors Clang's `-fsanitize=fuzzer-no-link`, which applies the
appropriate instrumentations but does not attempt to link to the
runtime library. More importantly, this suppresses the check in the
driver that fails the build if the library cannot be found. Since
libfuzzer is not distributed with Xcode, this allows users to build
it themselves or take it from a swift.org toolchain and use it
without having to physically copy/link it into their toolchain's
runtime directory.
As specified in SE-0441, -language-mode should appear in help output
while -swift-version should be the hidden alias.
Related to swiftlang/swift-driver#1894
Every time DarwinSDKInfo reads a new key out of SDKSettings, a boatload of test SDKSettings files need to be updated across several repositories and forks and branches. It’s tedious to be careful to update those with real values so that the tests are properly regression testing older SDKs. It’s important to be careful so that the tests are accurate, e.g. to prevent the scenario where DarwinSDKInfo starts reading a new key out of SDKSettings and assumes that it’s always available everywhere, when in reality it was only added a few releases ago and will break with older SDKs. If the test SDKSettings files continue to be updated ad hoc, it’s going to be really easy to copy/paste a default value everywhere, and then clients will see incorrect behaviors with the real SDKs, or even compiler crashes if the key is unconditionally read. Preemptively add all of the maybe-possibly-compiler relevant keys to the test SDKSettings files from the real SDKs so that the test files are an accurate representation and shouldn't need to be touched in the future. Where the test SDKSettings have intentionally doctored data, add a Comments key explaining what is changed from the real SDK, and alter the SDK name with a tag indicating the change.
rdar://168700857
Not having suport for this option causes confusing and non-obvious failures in
the LLDB testsuite, and some people build LLDB without also compiling the driver.
rdar://168107340
clang will start looking at CanonicalName and SupportedTargets soon, and error if those aren't as expected in the shipping SDKs. Pre-emptively add those to the test SDKSettings.
rdar://166277280
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.
Max Desiatov
Saleem Abdulrasool
Steven Wu
Tony Allevato
finagolfin
Ryan Mansfield
Henrik G. Olsson
Ramon Asuncion
Adrian Prantl
Ian Anderson
Dan Blackwell
Henrik G. Olsson
Allan Shortlidge
Doug Gregor
Owen Voorhees
Hamish Knight
Evan Wilde
Arnold Schwaighofer
Artem Chikin
Tobias Stadler
Anthony Latsis
Saleem Abdulrasool
Stefan Gränitz