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.
We were using "{{none}}" to mean "no Fix-Its" at all in the diagnostic
verifier, which is useful but narrow. Tweak it's meaning to mean "no
Fix-Its other than the ones we've explicitly checked for", which lets
us verify the exact set of Fix-Its produced as part of a diagnostic
rather than only matching a subset. I'll be landing some tests that
rely on this shortly.
Example:
@available(*, unavailable, renamed: "Sequence.enumerated(self:)")
func enumerate<Seq: SequenceType>(_ sequence: Seq) ->
EnumerateSequence<Seq>
This will allow us to reuse this logic to suggest fixes for APIs
turned into members by NS_SWIFT_NAME.
produced we'd emit two error messages. The first complained about the diagnostic
text being wrong and the second complained about the fixit being wrong.
That first one is incorrect to emit and super confusing. No testcase, since this
only affects -verify mode used by the testsuite.
Checked what it would look like to verify fix-its in every case, and
currently the tests are missing expected fix-its in 435 diagnoses in 60
test files.
So as an alternative, added support for a no fix-its marker “{{none}}”, and
added that marker to the c-style for deprecation tests where it applies.
This includes a few changes:
- Enhance diagnoseGeneralConversionFailure to not ignore constraints that are fully solved by
CSDiags' heuristics.
- Enhance dictionary/array literals diagnostics to handle non-compliance to their literal
protocols with a specific and custom error message.
- Add specific QoI for turning accidental use of array literals in dictionary context into
the right dictionary syntax (with a fixit).
Swift SVN r31696
ConstraintSystem::applySolution into its own helper function to reduce
indentation and make ConstraintSystem::applySolution much more simple
and obvious. NFC.
Swift SVN r31290
allowing these failures to hook into other diagnostic goodies (e.g. the
"did you mean to use '!' or '?'?" cases showing in the testsuite). That said,
by itself this doesn't have a huge impact, but avoids regressions with other
pending changes.
Swift SVN r31289
produce specific diagnostics about individual elements being incorrect instead of
complaining about the whole thing in aggregate.
This improves diagnostics immediately, but is also important to unblock future progress.
Swift SVN r31264
could lead to an "overlapping diagnostics" assertion because
two fixits were zapping whitespace. NFC, since noone except me
uses this.
Swift SVN r30929
other constraints intentionally ripped off, tell the recursive solution that
we can tolerate an ambiguous result. The point of this walk is not to
produce a concrete type for the subexpression, it is to expose any structural
errors within that subsystem that don't depend on the contextual constraints.
Swift SVN r30917
