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 <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
