[cfe-commits] clang patch for bug 14021

[Douglas Gregor]

On Oct 18, 2012, at 5:25 PM, Jan Voung <jvoung at chromium.org> wrote:

> 
> 
> 
> On Thu, Oct 18, 2012 at 2:24 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Thu, Oct 18, 2012 at 2:07 PM, Jan Voung <jvoung at chromium.org> wrote:
> >
> > On Thu, Oct 18, 2012 at 1:20 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >>
> >> On Thu, Oct 18, 2012 at 1:15 PM, Jan Voung <jvoung at chromium.org> wrote:
> >> > Attached is a creduce'd test case which compiles without any clang
> >> > errors,
> >> > but would have broken the assertion that "lock_hack == 0" that was in
> >> > Robert's patch.
> >>
> >> Better - and certainly not something that's totally unreasonable to
> >> commit, but it's helpful if the test case is as simple as possible so
> >> that, should it fail, there's not a lot of unrelated noise to
> >> investigate. Could you reduce this (by hand or automatically) further?
> >> I assume that's not the simplest it could possibly be. (though I'm
> >> happy to be corrected on that matter)
> >>
> >
> > Okay, making some progress manually reducing the test.  I'll upload another
> > version when I get it even smaller.
> 
> Thanks muchly.
> 
> 
> Okay here's a 100 line one.  Now it only triggers a single call of
> TryUserDefinedConversion and asserts on the second iteration.
>  
> 
> >
> >>
> >> > Well, I changed it to a print and grepped for the print so
> >> > that it wouldn't crash clang before clang had a chance to print other
> >> > errors.
> >>
> >> I'm not quite sure what you mean by this. We don't intend to commit
> >> that hack & so an assert seems like it'd be fine... the simplest
> >> program that produces that assertion is what we want for this test
> >> case I think.
> >>
> >
> > Oh, I just meant that I tweaked Robert's patch locally, to know when the
> > assert *would have* fired without actually having clang stop, so that clang
> > could continue and check that the rest of the test-case was still valid c++.
> > That was just for the purpose of reducing the test case.
> 
> Oh, fair enough - those autoreducers do have a tendency to go off into
> the weeds of invalid code.
> 
> While you've got that hack applied - have you tried running the entire
> regression suite? You might find existing test cases cover this bug,
> in which case no test would be required (though a nice reduction might
> be handy anyway, if you end up with it).
> 
> I tried running check-all with the hack applied, but it didn't trigger any
> new unexpected failures.

Thanks for checking this!

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121018/bb601cc6/attachment.html>