`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
You can now put `||` between two fix-its to indicate that the test succeeds if either of them is present. This is meant for situations where a fix-it might vary slightly in different subtests or test configurations.
Also fixes a bug in the diagnostic verifier where "expected-whatever" would search beyond the same line for its opening "{{", potentially finding one many lines away and giving a bad diagnostic and poor recovery behavior.
If, for instance, an error is emitted as a warning instead, the verifier now detects this and emits a single diagnostic saying that the warning was found but had the wrong kind, instead of emitting one diagnostic saying the error was missing and another saying the warning was unexpected.
In theory there are some edge cases we could handle better by doing two separate passes—one to detect exact expectation matches and remove them, another to detect near-misses and diagnose them—but in practice, I think the text + diagnostic location is likely to be unique enough to keep this from being a problem. (I would hesitate to do wrong-line diagnostics in the same pass like this, though.)
This commit fixes two weird bugs in -verify mode:
1. SourceLocs from the wrong SourceManager could be passed through a ForwardingDiagnosticConsumer into the DiagnosticVerifier.
2. -verify-additional-file did not error out correctly when the file couldn’t be opened.
No tests, as we only have basic tests for the diagnostic verifier.
This change adds a frontend flag, -verify-additional-file, which can be used to pass extra files directly to the diagnostic verifier. These files are not otherwise considered to be Swift source files; they are not compiled or even properly parsed.
This feature can be used to verify diagnostics emitted in non-source files, such as in module interfaces or header files.
The newer llvm StringRef library has removed the implicit StringRef to
std::string conversion. (See: llvm/llvm-project@adcd026)
This patch also uses a StringRef to compare another StringRef
eliminating the need to perform a StringRef to std::string conversion.
I am concerned that StringRef's are being stored in
ExpectedEducationalNotes, but as long as the StringRef does not out live
the definition this is totally cool then.
* [Diagnostics] Improve {{none}} fix-it verifier
* split two conditions
* define "none" constant
* support plural
* use Twine and add comment for replacement range
* check if {{none}} is at the end
* use noneMarkerStartLoc
* update second {{none}} error message
Co-Authored-By: Owen Voorhees <owenvoorhees@gmail.com>
* update test case for second {{none}}
* fix test case for new {{none}} check
* Use named struct
* set const
Co-authored-by: Owen Voorhees <owenvoorhees@gmail.com>
As an example of how this is useful, consider the case where
ClangImporter fails with
"unexpected error produced: could not build C module 'ctypes'"
It would be useful to know what the underlying Clang error was that
caused building the module to fail, but so far, `-verify` mode would not
output that; to get the error, it would be necessary to run the compiler
invocation again without `-verify`.
This change causes any remaining diagnostics that weren't in the input file
to be output if there were unexpected diagnostics in `-verify` mode.
I haven't added any tests for this because I didn't find a place that
contains tests for the `-verify` functionality itself (as opposed to
tests that use `-verify` mode). I think the large number of tests that
run with `-verify` should at least ensure, however, that this change
does not regress anything.
...by coalescing duplicates and dropping conflicts. Both cases can
happen with "expected-error 2 {{...}}": we might get multiple fix-its
providing the same new message, or one message might have diverged
into two, giving us incompatible changes.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Enables Chris's auto-apply-fixes mode for -verify: if an expected-*
annotation has the wrong message, or if the expected fix-its are
incorrect, this option will **edit the original file** to update them.
This is a tool for compiler developers only; it doesn't affect
normal diagnostic printing or normal fix-its.
