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)
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
