DiagnosticVerifier lexes the contents of expected diagnostics the same
way Swift parses string literals, to allow for escape codes. This makes
for problems when backslashes are followed by something that makes for a
valid escape. In particular, it reaches an llvm_unreachable if it
encounters `\(`, which would create a string interpolation in a string
literal.
Don't try to add expected lines in files that aren't parsed for them -
it will just lead to duplicated expected lines if run over and over.
Because we don't know whether the right choice is to add
-verify-additional-file or -verify-ignore-unrelated, we do nothing.
When replacing expected diagnostic content, we should consider
expected diagnostics targeting the same target, not targeting the line
the expected diagnostic is on.
`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 utility uses the walrus operator introduced in Python 3.8, but this
causes tests to fail in Amazon Linux 2 CI, which uses Python 3.7. Since
this is not a shipped product, that doesn't really matter, and 3.7 is an
ancient EOL version anyways. The premerge CI uses Python 3.9 and later,
so use that as a basis, just to avoid the same issue in the future in
case some Python 3.9 feature sneaks in.
rdar://164151931
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'.
