[libcxx] r216909 - Fix PR#20834 - 'is_trivially_destructible yeilds wrong answer for arrays of unknown bound' Thanks to K-ballo for the bug report. Update a few of the other tests while we're here, and fix a typo in a test name.

[John McCall]

On Oct 1, 2014, at 4:34 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> + John
> 
> John, could you advice here ?
> 
>> On Oct 1, 2014, at 4:20 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
>> 
>> On Oct 1, 2014, at 3:36 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
>>> 
>>> Richard Smith pointed out that destroying a pointer to an objective-C class might require an ARC call, and so the compiler needs to see the type to figure out if it is_destructible.
>>> 
>>> Note that is_destructible<ObjCForwardClass**>::value is true, so it’s just pointers to objective-C objects, not pointers in general.
>> 
>> Richard also pointed me to: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#retainable-object-pointers
>> 
>> So, while I agree with Argyrios that this changed the behavior of is_trivially_destructible for forward-declared objective-C classes,
>> I am now convinced that the old behavior was incorrect, and the new behavior is “better”.
>> 
>> One could argue that a forward-declared objective-C class is not a complete type, since the compiler doesn’t know how to destroy it, and if so, then is_destructible is not required to give any answer at all ("T shall be a complete type”).

Pointers to forward-declared Objective-C classes are still complete types.  They should be both destructible and (outside of ARC) non-trivially destructible.

I assume the problem here is ObjC property syntax, which usually looks like “foo.prop” where foo has ObjC pointer type.  Type-checking a property access really does require the type to be complete.  However, pseudo-destructor calls are not property accesses, and should not require the pointee type to be complete.

Does that answer your question?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141001/25392705/attachment.html>