[cfe-commits] Patch for review: enhancements/fixes to -verify

[Jonathan Sauer]

Hello,

>>> // expected-error at +2 {{should have foo}}
>>> #if !__has_feature(foo)
>>> #error should have foo
>>> #endif
>>> 
>>> Of course, it does require that the test-case writer will think
>>> to do this, in which case the unexpected no-op might not be
>>> written in the first place.  As mentioned in my response to
>>> Jordan Rose, perhaps this is where some test-case-writing
>>> guidelines on the clang website might come in handy.  (I'm not
>>> particularly volunteering here; I expect there will be clang
>>> veterans much better suited to this.)
>> 
>> Right, my point was not that it's hard to test, but that it's
>> dangerous: it adds to the list of things we need to be careful
>> about. I'm also concerned that we may have existing tests which
>> do something like that, which this change would neuter. If not,
>> then I'm happy to accept that this doesn't happen in practice.
> 
> Ok, I understand your point and it is impossible to cast-iron guarantee that 
> no-one in future will write a test in this way that won't false-pass: you 
> can't add a feature providing conditional checking without hitting this 
> problem.

Why not tell -verify whether to actually consider the #if, like for example:

#if <condition> // verify-evaluate
...
#endif

This would tell -verify to evaluate the #if condition and, if the result is false,
skip the block. The default would be for -verify to *not* evaluate #if's, just as
is currently the case.


Jonathan