On Tue, Aug 26, 2014 at 5:39 PM, Justin Bogner <[email protected]> wrote:
> Eric Fiselier <[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?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
