[PATCH] -verify enhancement to support matching "any" line in included files

Reid Kleckner rnk at google.com
Wed Jul 9 16:13:30 PDT 2014

We can use this for testing warnings in our builtin headers from
clang/lib/Headers.  Sometimes I've written tests against those that issue
notes in the system header, and it's impossible to match against them in a
non-brittle way.

Patch looks good.  I agree, there's no way to combine this bit with the
DiagnosticLoc SourceLocation, so an extra flag is necessary.

On Wed, Jul 9, 2014 at 2:05 AM, Andy Gibbs <andyg1001 at hotmail.co.uk> wrote:

> On Tuesday, July 08, 2014 6:54 PM, David Blaikie wrote:
>> Oh, that's fair. It'd be good to provide a comment in the test case
>> explaining this (the external use case), since I could imagine someone
>> coming back and thinking this is a bit silly to have for writing
>> internal test cases. (& hopefully we'll avoid proliferation of this
>> feature in internal test cases just by code review)
>> One thought on the code/design: would it be reasonable to, rather than
>> having the "MatchAllLines" flag, use an invalid ExpectedLoc? You might
>> still need a small-scoped "MatchAllLines" (I'd perhaps rename it to
>> "MatchAnyLine"?) due to the invalid ExpectedLoc used to determine
>> whether to report err_verify_missing_line, but after that you could
>> probably set ExpectedLoc to invalid and use that?
> We cannot use an invalid ExpectedLoc since we must also match the file
> name when checking the diagnostic lists, however I have implemented your
> requests in the attached patch.  With your approval, I will commit it.
> On Tuesday, July 08, 2014 6:10 PM, Jordan Rose wrote:
>> The analyzer would get mild use out of this too; we have "system header
>> simulators" shared across multiple files, and encoding line numbers in
>> each file that uses the header is somewhat brittle when the header
>> needs to change. Although I just realized that #line might be able to
>> get around that...
> #line is probably ok where a header file is simple, and indeed for
> internal test-cases this could be ideal if you are trying to pin down
> a diagnostic to a particular line of code.  I would beware of creating
> complications if more than one line ended up with the same line number!
> Cheers
> Andy
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140709/03df96a5/attachment.html>

More information about the cfe-commits mailing list