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

[Jordan Rose]

On Jun 12, 2012, at 11:15 AM, Andy Gibbs wrote:

> On Tuesday, June 12, 2012 12:12 PM, Jonathan Sauer wrote:
>> 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.
> 
> Ok, I think this should be possible without too much modification, but it 
> really depends on how the preprocessor supports comment extraction in 
> skipped blocks.  I can see how I might be able to implement this in either 
> of two ways:
> 
> 1. Have tags "verify-evaluate-all" and "verify-evaluate-normal" which enable 
> the test-case to specify regions where it should still extract comments from 
> skipped blocks.  I think this should be possible, but I wonder whether the 
> preprocessor might do a "fast skip" which might prevent even comments being 
> extracted.  I would have to check on this.  I think this will be more 
> feasible and flexible than trying to attach it to a #if directive.
> 
> 2. The alternative would be to have a tag "verify-post-process" which would 
> effectively cause the behaviour to revert to the old (current) behaviour for 
> this file.  This is certainly possible without much work.
> 
> Is there any interest in either or both of these suggestions?  If so, I can 
> look into doing it, though I would like to try and get at least the current 
> proposal committed and make this a "version 2", unless the interest is very 
> strong!

I am not. I think that we can always use FileCheck for the uncommon case, and -verify should work correctly in the common case. Personally I think having conditional checks is more useful than missing checks in dead code, since it lets you recompile the same set of tests with different language options and account for the differences. But the issue of silent acceptance is reasonable, and as such I'd be fine with sticking with our current scheme (where expectations are parsed independently of preprocessing, essentially) and using FileCheck (or multiple test files) when really necessary.

I /am/ interested in pretty much all of these enhancements, as I said before, but I would not want this committed as "version 1", with associated test changes, only to change the tests /back/ in "version 2", and if the community does not think the added value outweighs the issues, it should not be committed.

Feature-wise, the line number, the count, and the preprocessing are all fairly orthogonal. I second the idea of splitting them into multiple patches /even if/ they all end up going in.

I really do want to see this go in, though, and I'm still a proponent of conditional checks...but I'd prefer old-style non-conditional checks to additional flags and syntax.

Jordan