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.
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.
