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

Richard Smith richard at metafoo.co.uk
Tue Nov 27 23:49:12 PST 2012


On Tue, Nov 27, 2012 at 11:29 PM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>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.

--- 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:

void f() throw(int*, int());
void f() throw(int[], int(*)());

Thanks.
>
> 2012/11/28 WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>
>
> 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)
>>
>>
>
>
> --
> Best regards,
> Wen-Han Gu (Nowar)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121127/399fe2ae/attachment.html>


More information about the cfe-commits mailing list