[cfe-dev] The effects of exact diagnostic checking

Sebastian Redl sebastian.redl at getdesigned.at
Sat Feb 7 12:01:20 PST 2009


Hi,

I just implemented and committed exact diagnostic checking by -verify.
This doesn't mean that the text has to match exactly, but that the count
has to match exactly. This means: one expected-diag directive, one
actual diagnostic. The old situation was that one expected-diag matched
any number of actual diags, which masked some bugs.

If there are multiple diagnostics on one line for legitimate reasons
(usually expected-note {{previous definition here}} or the like) you can
now tell the checker how many there should be:
// expected-note 3 {{previous definition here}}
expected the diagnostic to appear exactly three times.

I've updated all test cases to this new scheme were there were no bugs,
but some are left failing. These are:

== Analysis/CFDateGC.m ==
I believe this is a bug. The analyzer warns about a leak twice for a line.
If it's actually two leaks, just adjust the comment.

== Driver/env-include-paths.c ==
I don't understand this test case. I don't think it does what it's
supposed to do, but I don't even know what it is supposed to do.

== Sema/tentative-decls.c ==
One line emits a redefinition error twice, with different previous
definitions. I think this is a bug.

== Sema/block-misc.c ==
Block pointer to block pointer to non-function emits the error for every
pointer level. I think it shouldn't.

== SemaCXX/default2.cpp ==
Invalid default arguments to members functions of inner classes are
diagnosed twice.

== SemaCXX/dcl_init_aggr.cpp ==
I've adjusted this test case to not fail, but I believe the situation
could be better. When declaring an object array and no appropriate
constructor is found, you get an error for every single element.

== SemaCXX/nested-name-spec.cpp ==
Some ambiguity errors are diagnosed multiple times.

== SemaCXX/using-directive.cpp ==
Same. This is why we wanted this functionality change in the first place.

== SemaCXX/member-name-lookup.cpp ==
Probably the same.

Sebastian



More information about the cfe-dev mailing list