<div class="gmail_quote">On Wed, Apr 4, 2012 at 12:46 PM, Jay Foad <span dir="ltr"><<a href="mailto:jay.foad@gmail.com">jay.foad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 26 March 2012 09:50, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
> Just thought I'd point out that removing the use of 'grep' from the test<br>
> suite has very significant benefits outside of any one platform.<br>
><br>
> I regularly find regressions in LLVM where a 'not grep' pattern fails to<br>
> match because the comments change in the output, leaving bugs and other<br>
> problems undiagnosed. FileCheck-izing these tests is of significant long<br>
> term maintenance value IMO.<br>
<br>
Just to check I'm on the right track, does this patch look OK? It<br>
converts a couple of small tests to use FileCheck instead of grep.<br>
Tested with "make check".</blockquote><div><br></div><div>There is nothing really wrong with these, but usually to be useful, you have to go a bit further.</div><div><br></div><div>I think the main thing missing here is the idea of "anchoring" the assertions that the test really cares about. You want to make sure that if the assertion passes, it in fact passes for the right reason. Let's look at simplified versions of the cases you're poking at:</div>
<div><br></div><div>1) Check that something is *not* present in the output. If we do this in the standard way that the grep-invocations do this (not grep 'Foo') the test can pass for completely inaccurate reasons: perhaps it simply produces no output at all. Instead, we want to anchor the negative assertions with some positive assertion that we're quite confident will be satisfied. In the case of 2007-06-16-Funcname.ll, it's not clear that we have any good 'no-op' thing to check for. In that case, you can run the command in two variants, one checking that Foo is present, and the second time that it is gone.</div>
<div><br></div><div>1.B) While not relevant for the examples you mailed, this can get more awkward when trying to check that something is not present inside a much larger test case. There you may want to pin down exactly within what *range* of things you are looking. This turns into a very common pattern:</div>
<div><br></div><div>CHECK: @my_test_function</div><div>CHECK-NOT: something_that_shouldnt_exist</div><div>CHECK: ret</div><div><br></div><div>2) Check that something *is* present in the output. This can get messed up for strange reasons -- usually if some unrelated output in the test happens to end up matching the output you're trying to assert. The typical way to handle this is similar to 1.B, simply pin it down with some context. Often, just the start is needed, unlike CHECK-NOT as the CHECK-NOT is active until the EOF or the next CHECK.</div>
<div><br></div><div><br></div><div>Hope this helps, and hopefully not *too* overly verbose. ;]</div></div>