[cfe-commits] [PATCH] Array exception type decay to pointer automatically

WenHan Gu (谷汶翰) wenhan.gu at gmail.com
Tue Nov 27 23:26:49 PST 2012


Hi Richard,

I've revised it again. I think this time all similar cases can run.
Please have a look.
http://llvm.org/bugs/attachment.cgi?id=9601&action=diff
PR14388: http://llvm.org/bugs/show_bug.cgi?id=14388

Thanks!

2012/11/22 Richard Smith <richard at metafoo.co.uk>

> Hi,
>
> On Wed, Nov 21, 2012 at 11:58 PM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>
> wrote:
> > Hi Richard,
> >
> > You're right. I've revised the patch.
> > Patch url: http://llvm.org/bugs/attachment.cgi?id=9583
> > (Sorry that my environment cannot upload it to GMail)
> >
> > I didn't put the logic inside CheckSpecifiedExceptionType, since the
> > QualType is pass-by-value, instead, I found I should put it before it.
> > I also made a test case.
>
> This still needs changes to handle the template instantiation case
> (the other caller of CheckSpecifiedExceptionType):
>
> template<typename T> struct S {
>   void f() throw(T);
> };
> S<int[10]> s;
>
> > 2012/11/21 Richard Smith <richard at metafoo.co.uk>
> >>
> >> On Tue, Nov 20, 2012 at 7:20 PM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>
> >> wrote:
> >> > Hi Richard,
> >> > Thanks your comments.
> >> >
> >> > However, I have no idea whether I should do this patch.
> >> > I've tested by gcc, clang and searched C++ spec draft n3242, the
> result
> >> > is
> >> > that both GCC and Clang failed on that and I cannot find any wording
> on
> >> > this
> >> > issue.
> >>
> >> I suggest you switch to using n3485.
> >>
> >> 15.4/2:
> >>
> >> A type denoted in an exception-specification shall not denote an
> >> incomplete type other than a class
> >> currently being defined or an rvalue reference type. A type denoted in
> >> an exception-specification shall not
> >> denote a pointer or reference to an incomplete type, other than cv
> >> void* or a pointer or reference to a
> >> class currently being defined. A type cv T, “array of T”, or “function
> >> returning T” denoted in an exception-
> >> specification is adjusted to type T, “pointer to T”, or “pointer to
> >> function returning T”, respectively.
> >>
> >> We are supposed to apply the decay from S[10] to S* before we check
> >> whether it's an incomplete-or-being-defined type or a pointer to an
> >> incomplete-or-being-defined type, so S[10] is OK.
> >>
> >> > Could you teach me more or could some else help?
> >> > Thanks!
> >> >
> >> >   1 struct S {
> >> >   2   void foo() throw (S[10])  { throw 0; }  // Both gcc and clang
> >> > failed
> >> > on this function
> >> >   3   void bar() throw (S)  { throw 0; }
> >> >   4 };
> >> >   5
> >> >   6 int main() {
> >> >   7   S().foo();
> >> >   8   S().bar();
> >> >   9 }
> >> >
> >> >
> >> >
> >> >
> >> > 2012/11/21 Richard Smith <richard at metafoo.co.uk>
> >> >>
> >> >> Hi,
> >> >>
> >> >> On Tue, Nov 20, 2012 at 1:54 AM, WenHan Gu (谷汶翰) <
> wenhan.gu at gmail.com>
> >> >> wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > I've done the patch and testcase to fix PR14338.
> >> >> > http://llvm.org/bugs/show_bug.cgi?id=14388
> >> >> >
> >> >> > Here's the patch, please review:
> >> >> > http://llvm.org/bugs/attachment.cgi?id=9574&action=diff
> >> >> >
> >> >> >
> >> >> > Is that okay to commit?
> >> >>
> >> >> A matching update is needed in SemaTemplateInstantiateDecl. Perhaps
> >> >> you could put this logic into CheckSepcifiedExceptionType (and either
> >> >> return the modified type or pass it through by reference)? One of the
> >> >> checks in  CheckSpecifiedExceptionType also needs updating. With your
> >> >> patch, we still reject this:
> >> >>
> >> >> struct S {
> >> >>   void f() throw (S[10]);
> >> >> };
> >> >>
> >> >> ... but we should accept it, because the type 'S' is supposed to be
> >> >> considered as complete in exception specifications inside its body.
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Wen-Han Gu (Nowar)
> >> >
> >
> >
> >
> >
> > --
> > Best regards,
> > Wen-Han Gu (Nowar)
> >
>



-- 
Best regards,
Wen-Han Gu (Nowar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121128/3fe351ca/attachment.html>


More information about the cfe-commits mailing list