<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 18, 2012, at 5:25 PM, Jan Voung <<a href="mailto:jvoung@chromium.org">jvoung@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 18, 2012 at 2:24 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Thu, Oct 18, 2012 at 2:07 PM, Jan Voung <<a href="mailto:jvoung@chromium.org">jvoung@chromium.org</a>> wrote:<br>
><br>
> On Thu, Oct 18, 2012 at 1:20 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Oct 18, 2012 at 1:15 PM, Jan Voung <<a href="mailto:jvoung@chromium.org">jvoung@chromium.org</a>> wrote:<br>
>> > Attached is a creduce'd test case which compiles without any clang<br>
>> > errors,<br>
>> > but would have broken the assertion that "lock_hack == 0" that was in<br>
>> > Robert's patch.<br>
>><br>
>> Better - and certainly not something that's totally unreasonable to<br>
>> commit, but it's helpful if the test case is as simple as possible so<br>
>> that, should it fail, there's not a lot of unrelated noise to<br>
>> investigate. Could you reduce this (by hand or automatically) further?<br>
>> I assume that's not the simplest it could possibly be. (though I'm<br>
>> happy to be corrected on that matter)<br>
>><br>
><br>
> Okay, making some progress manually reducing the test. I'll upload another<br>
> version when I get it even smaller.<br>
<br>
</div>Thanks muchly.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Okay here's a 100 line one. Now it only triggers a single call of</div><div>TryUserDefinedConversion and asserts on the second iteration.</div><div> </div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
><br>
>><br>
>> > Well, I changed it to a print and grepped for the print so<br>
>> > that it wouldn't crash clang before clang had a chance to print other<br>
>> > errors.<br>
>><br>
>> I'm not quite sure what you mean by this. We don't intend to commit<br>
>> that hack & so an assert seems like it'd be fine... the simplest<br>
>> program that produces that assertion is what we want for this test<br>
>> case I think.<br>
>><br>
><br>
> Oh, I just meant that I tweaked Robert's patch locally, to know when the<br>
> assert *would have* fired without actually having clang stop, so that clang<br>
> could continue and check that the rest of the test-case was still valid c++.<br>
> That was just for the purpose of reducing the test case.<br>
<br>
</div>Oh, fair enough - those autoreducers do have a tendency to go off into<br>
the weeds of invalid code.<br>
<br>
While you've got that hack applied - have you tried running the entire<br>
regression suite? You might find existing test cases cover this bug,<br>
in which case no test would be required (though a nice reduction might<br>
be handy anyway, if you end up with it).<br></blockquote><div><br></div><div>I tried running check-all with the hack applied, but it didn't trigger any</div><div>new unexpected failures.</div></div></div></blockquote><br></div><div>Thanks for checking this!</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br></div><br></body></html>