[cfe-dev] [cfe-commits] Patch for review: enhancements/fixes to -verify
andyg1001 at hotmail.co.uk
Mon Jun 11 11:11:27 PDT 2012
On Monday, June 11, 2012 6:53 PM, Jordan Rose wrote:
> Personally, I think this is great. Being able to make expected-* be
> preprocessor-dependent means it's a lot easier to write conditional
> tests, which previously you'd need to use different FileCheck
> invocations to handle.
Thanks! Yes, conditional tests was the main impetus behind making the
> I'm less excited about the non-deterministic number of warnings,
> since I don't think we should encourage tests that don't know exactly
> how many warnings will be emitted. '+' is kind of a special case for
> notes that we trigger more than once but don't really care about. But
> since this is fully backwards-compatible, this isn't a strong objection.
This is one of those things that fell out while thinking about use-cases.
Making the feature possible doesn't need to mean that those writing test
cases should be advised to make use of them: this comes down to having some
sort of test-case-writing guidance for those developing on clang. Where I
started from, was looking for a way of swallowing up uninteresting
diagnostics in a set of test-cases for a separate project, while still
catching the important ones. In the particular case in question, the exact
number of the uninteresting diagnostics could not be easily determined since
the test-cases depended on include file containing quite a number of
platform-specific #if blocks. I had seen the "+" token for "1 or more" but
I was looking for a "0 or more". I considered implementing a "*" token
(again the regex-style grammar), but then thought that a clearer
implementation would be the 0+ route and the full set, including a min/max
range, followed from that for completeness' sake.
> Good catch on the comments-in-the-line problem. I just hit that with
> a FileCheck test recently.
Yes, easy to miss! The problem here of course is that #error takes the
whole line for its output, but since there was a separate parse operation on
the source file for checking the diagnostics, the comment was getting
extracted even though in the normal compile operation, the comment is not a
> I didn't see anything obviously out-of-place here, but the -verify code
> isn't my area of expertise, so please wait for someone else's review.
> Thanks for coming up with this!
More information about the cfe-dev