swift-frontend -verify -verify-ignore-unrelated does not expect matchers
for files in unchecked files, but it still emits diagnostic output like
this:
```
/path/to/sdk/file.h:19:29: remark: diagnostic produced elsewhere: did not add safe interop wrapper
struct _LIBCPP_TEMPLATE_VIS input_iterator_tag {};
```
update-verify-tests errors on unexpected input to ensure nothing is
accidentally missed. This adds the pattern above to the set of expected
inputs.
This parses existing expected diagnostics in the source file even if
they have a mismatching prefix. This lets the script know that the }}
closing an unrelated expected-expansion block is not due to a mistake in
parsing. Unrelated diagnostics are otherwise left as they are.
The functions never ended up in the module interface because they
weren't public. Fixing this revealed that the swift-frontend -verify
invocation didn't enable lifetimes. It also revealed that
swift-function-caller-generator emits both an @lifetime and an
@_lifetime version for functions annotated with @_lifetime. This will be
fixed in the next commit.
compile.swift turned out to be broken and passing by compiling an almost
empty file. This will make the changes in the next following commits
easier to follow along.
By hashing the output, the test updater won't trigger for failures
unrelated to the test file being outdated. That is, if the generated
test output hasn't changed, then regenerating the test surely won't fix
it. This serves two purposes:
- it allows someone to make edits to the output (e.g. add comments) and
not have them overwritten all the time
- only one test updater is allowed to make updates each test failure,
so if the generated file hasn't changed, it shouldn't prevent other
test updaters from executing
This adds an automatic test updater that checks for GENERATED-BY:
comments containing a command whose stdout is used to populate a file,
or a split-file slice in a file.
The test updater applies the same lit substitutions as would be applied
in a RUN: line, allowing Swift tool usage in the run line.
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'.
Henrik G. Olsson
Henrik G. Olsson