On 8/26/14, 6:40 PM, Chandler Carruth wrote:
On Tue, Aug 26, 2014 at 5:39 PM, Justin Bogner <[email protected] <mailto:[email protected]>> wrote: Eric Fiselier <[email protected] <mailto:[email protected]>> writes: >> I don't think we should spend our time fixing warnings (coverity or >> otherwise) is code that is supposed to produce compile >> errors... seems a waste. > > I don't want to revive this thread, but I really want to address this. > > Its *more* important to fix problems in tests that are supposed to > fail to compile than any other test. Its super easy to have code fail > to compile. What we are trying to test is that it fails for the > *right* reason. Any other errors, such as the one in this patch, > could cause the test to "pass" incorrectly. What if this test was > "passing" because of the missing return? I suspect the right answer here is to rework the libc++ testing infrastructure so that it actually checks *why* the test failed in some way, rather than the current "Exit code 1? Great!" approach. I guess this is tricky if we want to be able to test libc++ with different compilers or avoid version locking it too tightly with clang, though. I would really like to see more detailed testing. Maybe we could have optional checks on the text of the output with FileCheck (or clang's -verify) when using clang, and otherwise fall back on exit status?
A first-order approximation, I suppose, would be to arrange for filecheck to check that clang/gcc/whatever spits out an error message containing the word "error" and the particular offending line number. I think this should be relatively compiler agnostic.
Jon
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-- Jon Roelofs [email protected] CodeSourcery / Mentor Embedded _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
