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

[Manasij Mukherjee]

How about the second case in the bug report ?

struct A {
    ~A(){}
};
void foo(A* a) {
    a->~decltype(A())();
}

This does not seem valid to me.
There is a test  (CXX/special/class.dtor/p10-0x.cpp) that expects this
construct to build properly.

If both of these are not valid, does removing the if block I mention solve
the issue?
Or does this bug go deeper ?


On Mon, Feb 23, 2015 at 2:53 AM, Richard Smith <richard at metafoo.co.uk>
wrote:

> [class.dtor] (12.4)/1:
>
> "A declaration of a destructor uses a function declarator (8.3.5) of the
> form
>
>     ptr-declarator ( parameter-declaration-clause ) exception-specificationopt
> attribute-specifier-seqopt
>
> where the ptr-declarator consists solely of an id-expression, an optional
> attribute-specifier-seq, and optional surrounding parentheses, and the
> id-expression has one of the following forms:
>
> -- in a member-declaration that belongs to the member-specification of a
> class but is not a friend declaration (11.3), the id-expression is ~class-name
> and the class-name is the injected-class-name (Clause 9) of the
> immediately-enclosing class;
>
> [... bullets 2 and 3 do not apply ...]"
>
> A decltype-specifier is never a class-name, so ~decltype(...) cannot be
> used to declare a destructor.
>
> On Sun, Feb 22, 2015 at 12:51 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
>
>>
>>
>> On Sun, Feb 22, 2015 at 7:56 AM, Manasij Mukherjee <manasij7479 at gmail.com
>> > wrote:
>>
>>> Hi,
>>> I am trying to fix this bug,
>>> http://llvm.org/bugs/show_bug.cgi?id=22508
>>>
>>> In short,
>>> struct A
>>> {
>>>     ~decltype(auto){}
>>> };
>>> is accepted when it should not be.
>>>
>>> In Parser::ParseUnqualifiedId (ParseExprCXX.cpp:2488 ),
>>>
>>> // Parse the '~'.
>>>     SourceLocation TildeLoc = ConsumeToken();
>>>
>>>     if (SS.isEmpty() && Tok.is(tok::kw_decltype)) {
>>>       DeclSpec DS(AttrFactory);
>>>       SourceLocation EndLoc = ParseDecltypeSpecifier(DS);
>>>       if (ParsedType Type = Actions.getDestructorType(DS, ObjectType)) {
>>>         Result.setDestructorName(TildeLoc, Type, EndLoc);
>>>         return false;
>>>       }
>>>       return true;
>>>     }
>>>
>>> After this, clang handles the identifier case.
>>>
>>> Removing this block results in clang reporting the correct diagnostic:
>>> "error: expected a class name after '~' to name a destructor"
>>>
>>> Why is this block present ?
>>> Can anyone point out what is the expected behavior ?
>>>
>>
>> 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 can't find any particular words in the spec about taht, but I could
>> believe it's not intended (I didn't test it, at least) for dtor
>> declarations/definitions to use this syntax.
>>
>> http://llvm.org/bugs/show_bug.cgi?id=15801 was also filed about this
>>
>>
>>>
>>> Thanks
>>> Manasij Mukherjee
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150223/1d892678/attachment.html>