[LLVMbugs] [Bug 18879] New: type-name alias in unqualified-id used in explicit destructor call not handled correctly

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Feb 17 21:23:33 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18879

            Bug ID: 18879
           Summary: type-name alias in unqualified-id used in explicit
                    destructor call not handled correctly
           Product: clang
           Version: 3.4
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: filip.roseen at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12080
  --> http://llvm.org/bugs/attachment.cgi?id=12080&action=edit
foo.cpp

struct  A { };
typedef A A_alias;

int main () {
  A ().A_alias::~A_alias (); // valid according to [class.dtor]p13
}

-----------------------------------------------

testcase.cpp:5:18: error: expected the class name after '~' to name a
destructor
  A ().A_alias::~A_alias (); // valid according to [class.dtor]p13
                   ^
1 error generated.

-----------------------------------------------

As stated under [class.dtor]p13:

  > In an explicit destructor call, the destructor name appears as a ~
  > followed by a type-name or decltype-specifier that denotes the
  > destructors class type.


  > <snip>

  > An explicit destructor call must always be written using a member
  > access operator (5.2.5) or a qualified-id (5.1)


There's an example in the mentioned section matching our testcase
`B_ptr->B_alias::~B_alias ();` (which, as implied, is legal).


gcc and icc both handles the case correctly (and accepts the code).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140218/2ae007be/attachment.html>


More information about the llvm-bugs mailing list