[cfe-dev] When does ~decltype(expr) make sense ?

[Richard Smith]

On Mon, Feb 23, 2015 at 11:13 AM, Manasij Mukherjee <manasij7479 at gmail.com>
wrote:

> So, an extra condition takes care of not allowing the decltype when
> declaring the dtor.
> ! getCurScope()->isClassScope()
>
> Am I correct ?
>

No; ~decltype can appear in class scope in default arguments, default
member initializers, initializers for static data members, template
arguments, and so on.

The bug is due to confusion over the contract of Sema::getDestructorType.
It is assuming that a null ObjectType implies that an error has already
been produced, but ParseUnqualifiedId calls it with a null ObjectType to
mean simply that no ObjectType was provided. One side of this interface is
wrong; we need to pick which one, and produce a diagnostic on that side if
ObjectType is in fact null.

(We should be using TypeResult here rather than ParsedType, to make it
clear whose responsibility it is to produce the diagnostic.)

> you can use ~decltype(...)() to invoke a destructor
> Why is that allowed?
> And what exactly is a valid use of this ?
>
> From the report,
> A().~decltype(auto); // ICE, and A can be an empty struct
>
> Does the standard say anything about what can the decltype contain ?
> Should the compiler figure something out from the auto here ?
>
> On Tue, Feb 24, 2015 at 12:26 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On Sun, Feb 22, 2015 at 3:24 PM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Feb 22, 2015 at 2:33 PM, Manasij Mukherjee <
>>> manasij7479 at gmail.com> wrote:
>>>
>>>>
>>>>
>>>>> 5.1.1 [expr.prim.general] in paragraph 8 states that "The form ~
>>>>> decltype-specifier also denotes the destructor, but it shall not be used as
>>>>> the unqualified-id in a qualified-id."
>>>>>
>>>>> I implemented this a while ago, but it looks like (r146155) it was for
>>>>> expressions (x.~decltype(*x)(), for example) not necessarily for dtor
>>>>> declarations.
>>>>>
>>>>> I do not clearly understand what this sentence implies.
>>>> Could you elaborate?
>>>>
>>>> Also, if the meaning is as you interpreted it, what is the rationale
>>>> for allowing x.~decltype(*x)() ?
>>>>
>>>
>>> Not quite sure I understand this question (though I did make a mistake
>>> in that example, should've been x->~decltype(*x)())
>>>
>>
>> That doesn't work either: decltype(*x) is a reference type. It'd need to
>> be something ridiculous like
>>
>>   X x;
>>   x.~decltype(x)();
>>   new (&x) X;
>>
>> 5.1.1 talks about how ~decltype(...) is a valid unqualified id, except in
>>> the case of a qualified id (ie, you can't write "x::y::~decltype(...)"). So
>>> that's how x->~decltype(*x)() is valid, as far as I see/read/understand it
>>> - wherever you can use an unqualified-id that would name a dtor, you can
>>> use ~decltype(...) too (ecxept in the qualified-id case).
>>>
>>
>> Right; you can use ~decltype(...)() to invoke a destructor, but you can't
>> use ~decltype to declare a destructor.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150223/26ccad86/attachment.html>