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

[David Blaikie]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150222/8a25a86f/attachment.html>