Hello! Revision 4 uploaded. http://llvm.org/bugs/attachment.cgi?id=9603&action=diff
2012/11/28 Richard Smith <[email protected]> > On Tue, Nov 27, 2012 at 11:29 PM, WenHan Gu (谷汶翰) <[email protected]>wrote: > >> Wrong file, sorry. >> http://llvm.org/bugs/attachment.cgi?id=9602&action=diff >> > > Thanks! > > +/// @param[in,out] T It will be decayed to a pointer automatically when > input > > Please use \param, not @param, to match the prevailing style in Clang. > > // C++ 15.4p2: A type denoted in an exception-specification shall not > denote > // an incomplete type. > - if (RequireCompleteType(Range.getBegin(), T, > + if (!T->isArrayType() && !T->isFunctionType() && > + RequireCompleteType(Range.getBegin(), T, > diag::err_incomplete_in_exception_spec, > /*direct*/0, Range)) > return true; > > + if (T->isArrayType()) > + T = Context.getArrayDecayedType(T); > + else if (T->isFunctionType()) > + T = Context.getPointerType(T); > > Maybe move this before the RequireCompleteType call, and make the > RequireCompleteType the 'else' for these? It'd also be nice to reference > the relevant paragraph in the standard here. > Yes! > > --- a/test/SemaCXX/exception-spec-decay.cpp > +++ a/test/SemaCXX/exception-spec-decay.cpp > @@ -0,0 +1,33 @@ > +// RUN: %clang -x c++ -fexceptions -emit-llvm -S -o - %s | FileCheck %s > > Please put this test in test/CodeGenCXX/, use %clang_cc1, and specify a > -triple. > > + // CHECK-next: _ZTIPi > > Use "CHECK-NEXT:". FileCheck will ignore this line. > > A -fsyntax-only test would be useful. Something like: > I think checking mangled type string is more clear. Isn't it? Therefore, I move it into CodeGenCXX. Thanks! > > void f() throw(int*, int()); > void f() throw(int[], int(*)()); > > Thanks. >> >> 2012/11/28 WenHan Gu (谷汶翰) <[email protected]> >> >> 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 <[email protected]> >>> >>>> Hi, >>>> >>>> On Wed, Nov 21, 2012 at 11:58 PM, WenHan Gu (谷汶翰) <[email protected]> >>>> 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 <[email protected]> >>>> >> >>>> >> On Tue, Nov 20, 2012 at 7:20 PM, WenHan Gu (谷汶翰) < >>>> [email protected]> >>>> >> 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 <[email protected]> >>>> >> >> >>>> >> >> Hi, >>>> >> >> >>>> >> >> On Tue, Nov 20, 2012 at 1:54 AM, WenHan Gu (谷汶翰) < >>>> [email protected]> >>>> >> >> 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) >>> >>> >> >> >> -- >> Best regards, >> Wen-Han Gu (Nowar) >> >> > -- Best regards, WenHan Gu (Nowar)
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
