[llvm-bugs] [Bug 38651] New: Microsoft C++ doesn't consider anonymous namespaces for back-referencing

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Aug 20 16:38:09 PDT 2018


https://bugs.llvm.org/show_bug.cgi?id=38651

            Bug ID: 38651
           Summary: Microsoft C++ doesn't consider anonymous namespaces
                    for back-referencing
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: zturner at google.com
                CC: llvm-bugs at lists.llvm.org, rnk at google.com

If you have this code:

// foo.cpp
namespace {
  namespace {
    int X;
  }
}
//

We mangle this as:
?X@?A0xE81D4E31@?A0xE81D4E31@@3HA

while cl mangles this as:
?X@?A0xed6ebf2d at 1@3HA

It's fine that the hash values don't match, but it's a bug that we don't store
this hash in the back-reference table.  Consider this example instead:

namespace X { namespace X {
  namespace { namespace {
    namespace Y { namespace Y {
      int Z;
    } }
  } }
} }

Now we mangle this as:
?Z at Y@1?A0xE81D4E31@?A0xE81D4E31 at X@2 at 3HA 

And Microsoft's own undname demangles this as:
int A0xE81D4E31::X::`anonymous namespace'::`anonymous namespace'::Y::Y::Z

which is obviously wrong.  

This example might seem contrived, but you can make it matter in a more
realistic example too:

// 
namespace {
  struct X {};
  X anonFunc(X x, X y);
  template<typename T> void foo(T t);
}

Here, we mangle anonFunc as:
?anonFunc@?A0xE81D4E31@@YA?AUX@?A0xE81D4E31@@U1?A0xE81D4E31@@0 at Z

which undname demangles as:
struct `anonymous namespace'::X __cdecl `anonymous namespace'::anonFunc(struct
`anonymous namespace'::A0xE81D4E31,struct `anonymous namespace'::A0xE81D4E31)

(Note both function parameter types are nonsensical).

-- 
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/20180820/81ce8c57/attachment.html>


More information about the llvm-bugs mailing list