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

[Richard Smith]

On Wed, Nov 28, 2012 at 12:45 AM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>wrote:

> Hello! Revision 4 uploaded.
> http://llvm.org/bugs/attachment.cgi?id=9603&action=diff
>
> 2012/11/28 Richard Smith <richard at metafoo.co.uk>
>
>> 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.
>>
>
> 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!
>

We generally like to test things as early in the compilation process as
possible. Also, the Sema test and the CodeGen test are checking different
things; it would be entirely feasible for either test to pass while the
other test fails.

Checked in with a Sema testcase in r168822. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121128/c0273784/attachment.html>