When replacing expected diagnostic content, we should consider
expected diagnostics targeting the same target, not targeting the line
the expected diagnostic is on.
This adds a lit plugin wrapping the core of update-verify-tests. When
lit is invoked with --update-tests it will call the plugin, which checks
if the failure is due to a -verify mismatch. If it is, it tries to
repair the test. If the source file was originally created by
split-file, the changes are propagated to the parent file.
No tests are added, because I don't want to run nested llvm-lit tests
in Swift's test suite, but the core functionality is tested through
update-verify-tests.py.
This fixes a bug that was introduced where two diagnostics on the same
line, with the same content, would be emitted separately if they
occurred on separate columns. This despite the fact that neither of
these checks specify the column when emitted. The checks are now
properly merged again.
`expected-expansion` can be a bit unergonomic to use, because it requires
pointing out not only the line, but also the column (which is not always
obvious), and the nested diagnostics have to refer to absolute lines
that aren't present in the source file. This makes both creating and
updating these test cases easier through automation.
This drops the dependency on the system libxml2 from the tools shipped
in the toolchain bundle. libxml2 is disabled entirely for the LLVM/lld
build, which uses it for processing the Windows manifest files. LLDB is
changed to link against the static libxml2 built for the FoundationXML
library. This is technically incorrect since the runtime may be
cross-compiled for a different platform than what the toolchain is built
to run on, but build-script is already mixing toolchain and runtime
content in inconsistent ways, so this is no worse off than we are
already.
libxml2 is updated pretty frequently in inconsistent ways, resulting in
failures to launch due to version incompatibilities.
This ports clang's test suite for update-verify-tests from C to Swift,
and adjusts update-verify-tests as needed. The main differences are the
Swift -verify output format being quite different, as well as Swift's
'-verify-additional-prefix foo' working differently than clang's
'-verify=foo'.
This script is used to automatically update test cases using -verify in
clang's test suite. Swift also has a similar -verify test functionality,
and while it can automatically fix some of them using -verify-apply-all,
this functionality only updates existing checks - it doesn't add or
remove any, and it doesn't handle newer and more complex things like
expected-expansion. Handling that type of complexity feels out of scope
to embed in the compiler, so let's copy clang's approach.
This commit adds this script as is from clang. It doesn't work at all
for Swift in its current form, as the output from Swift's -verify is
formatted differently than in clang. This will be fixed in subsequent
commits.
This could have been done by adapting the script as-is in the
llvm-project repository (since it only exists in the Swift fork, not
upstream), but tests using swift-frontend would have to reside in the
swift repo, and modifying a script in one repo with tests in a different
repo sounds like a recipe for endless CI issues.
Enable the use of the early swift-driver to build the Swift toolchain.
This is the first step towards removing the accumulated debt and
workarounds when building the toolchain on Windows.
This prepares the swift-driver building on Windows. By statically
linking the runtime and its dependencies, this will allow us to avoid
the runtime shuffling that is required to get the runtime required to
get the swift-driver working.
Use the experimental SDK to build the toolchain and consume the
redistributable. This is going to ensure that we build the entire
toolchain against a stable point and run against the runtime that we
build against.
`os.path.dirname` removes the last path component of a path. If there was a git failure in `~/src/swift`, this means that we show `~/src` as the repo name, which isn’t very helpful. Use `os.path.basename`, which returns the last path component, ie. `swift`.
functions.
These were introduced in an early draft implementation of async let, but
never used by a released compiler. They are not used as symbols by any
app binaries. There's no reason to keep carrying them.
While I'm at it, dramatically improve the documentation of the remaining
async let API functions.
