[libcxx] r216317 - Add return statement to a test class's assignment operator. Defect found by Coverity Scan.

[Eric Fiselier]

I'm not opposed to the change but using Filecheck really hurts our ability
to test standalone.
Also, we don't have that many compilation failures tests. I'm not sure how
badly this change is needed.

/Eric


On Tue, Aug 26, 2014 at 6:54 PM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:

>
>
> On 8/26/14, 6:40 PM, Chandler Carruth wrote:
>
>>
>> On Tue, Aug 26, 2014 at 5:39 PM, Justin Bogner <mail at justinbogner.com
>> <mailto:mail at justinbogner.com>> wrote:
>>
>>
>>     Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca>> 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
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
> _______________________________________________
> 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/20140826/feca4c50/attachment.html>