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

Manasij Mukherjee manasij7479 at gmail.com
Mon Feb 23 13:27:53 PST 2015


> One side of this interface is wrong
Any reasons for handling this in Sema instead of Parser?

The following (in ParseUnqualifiedId) seems to work:

      if (ObjectType.get().isNull()) {
        Diag(Tok, diag::err_destructor_tilde_identifier);
        return true;
      }

      if (DS.getTypeSpecType() == DeclSpec::TST_decltype_auto) {
        Diag(Tok, diag::err_destructor_tilde_identifier);
        //needs a better diag. which one ?
        return true;
      }

The first one handles the declaration of dtor using decltype.
But the assertion failure for
A().~decltype(auto);
remains.
The second one handles that.


On Tue, Feb 24, 2015 at 1:39 AM, Richard Smith <richard at metafoo.co.uk>
wrote:

> 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/20150224/3a408cd8/attachment.html>


More information about the cfe-dev mailing list