<html>
    <head>
      <base href="http://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - No diagnostic for invalid destructor name where the class-name should not resolve to the injected-class-name"
   href="http://llvm.org/bugs/show_bug.cgi?id=20686">20686</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>No diagnostic for invalid destructor name where the class-name should not resolve to the injected-class-name
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>clang
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>C++
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedclangbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>hstong@ca.ibm.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>dgregor@apple.com, llvmbugs@cs.uiuc.edu
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>As confirmed by the resolution of Core Issue 244 (and dating back to C++98),
the lookup for the class-name "A" after the '~' below should be done in the
scope where the lookup for "AA" was done.
Since the lookup is performed prior to transformation into a class member
access expression (see 9.3.1 [class.mfct.non-static]), dual destructor lookup
(3.4.5 [basic.lookup.classref]) does not apply and the question raised in Core
Issue 399 does not arise.
A diagnostic is expected since ~A where the class-name resolves to M::A does
not name a member of N::A<int>.

Both GCC and EDG produce an error on this case.

### SOURCE:
$ cat nameADtor.cc 
namespace N {
   struct A { void selfDestruct(); };
}

namespace M {
   typedef N::A AA;
   union A;
}

void N::A::selfDestruct() {
   ::M::AA::~A();
}


### COMPILER INVOCATION AND OUTPUT:
$ clang -cc1 -Wall -Wextra -pedantic-errors -x c++ -std=c++03 nameADtor.cc 
(No messages)


### EXPECTED BEHAVIOUR:
nameADtor.cc:11:14: error: expected the class name after '~' to name a
destructor
   ::M::AA::~A();
             ^
1 error generated.


### COMPILER VERSION INFO:
$ clang++ -v
clang version 3.5.0 (trunk 214060)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Selected multilib: .;@m64</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>