> 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? /Eric On Sat, Aug 23, 2014 at 8:14 PM, Eric Fiselier <[email protected]> wrote: > If we want to enable warnings and use static analysis tools these sort of > errors simply need to be fixed to prevent noise. > > /Eric > On Aug 23, 2014 7:06 PM, "Chandler Carruth" <[email protected]> wrote: > >> >> On Sat, Aug 23, 2014 at 6:01 PM, Jonathan Roelofs < >> [email protected]> wrote: >> >>> Wait a second, this test is *supposed* to be a compile failure, but not >>> for the reason I originally thought. It's testing that unique_ptr requires >>> the deleter have a public default constructor. Because it fails to >>> compile, '-Wall -Wextra -pedantic -Werror' won't help us here :( >>> >> >> Hah. >> >> 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. >> >> _______________________________________________ >> 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
