[cfe-commits] clang patch for bug 14021
dgregor at apple.com
Thu Oct 18 17:26:34 PDT 2012
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits