<div dir="ltr">The way LIT works, it's better to have the number of things tested in each file be as small as possible (because testing halts at the first failure), so I'd prefer to keep it split out.<div><br></div><div>The comments should be fixed though. I guess I wasn't paying enough attention :)</div><div><br></div><div>With that one thing fixed, this LGTM and is ready to land.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 10:18 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Sep 11, 2014 at 1:09 PM, Dan Albert <<a href="mailto:danalbert@google.com">danalbert@google.com</a>> wrote:<br>
> I've changed the test so that it calls __cxa_throw_bad_array_new_length()<br>
> (I'm mad at whoever gave this function such a long name) directly rather<br>
> than expecting the compiler to call it for bad input to new[]. That check<br>
> can go in the compiler tests.<br>
<br>
</span>I'm okay with that approach,  but should this test then be merged back<br>
into test_aux_runtime.cpp instead of being in a separate file?<br>
Regardless, the comments at the top of the file should probably be<br>
corrected, unless we're adding them as a FIXME to a commented-out<br>
version of the original test case.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> On Thu, Sep 11, 2014 at 6:39 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Wed, Sep 10, 2014 at 11:52 AM, Dan Albert <<a href="mailto:danalbert@google.com">danalbert@google.com</a>> wrote:<br>
>> > Sorry, I got used to relying on phabricator to keep track of things, and<br>
>> > forgot about this one.<br>
>><br>
>> No worries!<br>
>><br>
>> > Could you split the test in to a separate file and add `// XFAIL: *` at<br>
>> > the<br>
>> > top? That way you can commit it with the guts of the patch and we don't<br>
>> > have<br>
>> > to worry about forgetting to submit the test later.<br>
>> ><br>
>> > Other than that, LGTM.<br>
>><br>
>> I've split the test out into its own file, and have attached the patch<br>
>> here.<br>
>><br>
>> Since I don't have a way to test this locally, and no other tests have<br>
>> XFAIL lines, I'm not quite comfortable committing this without someone<br>
>> who can run the tests confirming that it runs cleanly.<br>
>><br>
>> Thanks!<br>
>><br>
>> ~Aaron<br>
><br>
><br>
</div></div></blockquote></div><br></div>