[CodeView] Enable debugging of captured variables within C++ lambdas

[bwyma]

Summary

When emitting CodeView debug information, C++ lambda types need a unique identifier so Visual Studio can match the forward reference for the type to the definition. Currently they are all named "<unnamed-tag>". This patch, also necessary for D32498, will enable debugging of captured variables within lambdas using Visual Studio.

Previous LF_CLASS type record for a lambda looks like this:

Class (0x100A) {
  TypeLeafKind: LF_CLASS (0x1504)
  ...
  Name: main::<unnamed-tag>
}

After this change the type record looks like this:

Class (0x100A) {
  TypeLeafKind: LF_CLASS (0x1504)
  ...
  Name: main::<unnamed-tag>
  LinkageName: .?AV<lambda_0>@?0??main@@9@
}

Manufacturing a better "name" for the lambda object is not necessary to allow proper debugging of captured variables.

[rnk]

I don't think this is enough, this issue generalizes to more than just lambdas. The more general problem is this:

• C++ classes with methods create a cycle in the type hierarchy (class refers to method, method refers to class)
• Some C++ classes without names may not be externally visibible
• CodeView requires class identifiers to enable this circular reference.

Here is a program that will need identifiers that your patch misses:

void foo() {
  struct {
      void bar() {}
  } obj;
  obj.bar();
}

I think we want to ask the question "does this class have any non-trivial methods" here, and if so, emit an identifier for codeview.

[bwyma]

I updated the patch file to generalize the fix for more than just lambdas.

I think we want to ask the question "does this class have any non-trivial methods" here, and if so, emit an identifier for codeview.

I believe this is also insufficient because data member pointers also contain a class id referring to the forward reference. For example:

struct { int bar; } two = { 42 };
int decltype(two)::*ptr2unnamed = &decltype(two)::bar;

I added this example and Reid's example into the test case included with my patch.

[rnk]

llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp

806

The indentation seems off which suggests the patch may contain tabs. Please check that there are none before submitting.

808

This boolean condition is complicated. Can you find a way to break it up and add comments to clarify the intent? Basically, externally visible types with C++ manglings always need unique names. When emitting codeview, non-externally visible unnamed types also need unique names.

However, doesn't this conflict with the goal of D32498? At this point, Clang will put unique names on every unnamed type in C++ mode. That's fine with me, FWIW.

810

My final concern is that the C++ mangled names we generate in this case are not necessarily unique across the whole program, which is what we mean when we say "unique name" in this context. Fixing that is out of scope for this patch, but we should file a bug for it. I guess here is a case where we'll have two unrelated types with the same identifier:

// a.cpp
namespace { struct { int x; } x; }
int getx() { return x.x; }
// b.cpp
namespace { struct { float y; } x; }
float gety() { return x.y; }

I think we're safe for types inside non-inline functions, because we mangle in the parent function as a scope, so no other TU will collide with that mangling. Only anonymous namespaces have this problem. MSVC addresses this by including a hash (MD5?) of the main source file path in the mangled name for the anonymous namespace.

llvm/tools/clang/test/CodeGenCXX/debug-info-codeview-unnamed.cpp

36

We should have a test that in C mode, anonymous structs do not get identifiers. If we already have it, that's fine.

58

Maybe "Non-externally visible named structures do not ..." to be specific.

Also, are you sure? I would expect the debugger to require a forward reference for these methods and data members, and how can that work without a unique name?

[bwyma]

The indentation seems off which suggests the patch may contain tabs.

Fixed.

This boolean condition is complicated. Can you find a way to break it up and add comments ...

Fixed.

However, doesn't this conflict with the goal of D32498?

This patch fixes the identifier emission for C++ types. Patch D32498 is for C types.

My final concern is that the C++ mangled names we generate in this case are not necessarily unique ...

Your point is correct, the identifier could be more robust. But this patch still improves cases which can't be debugged currently.

We should have a test that in C mode, anonymous structs do not get identifiers.

I added a new test for your review.

Maybe "Non-externally visible named structures do not ..." to be specific.

Fixed.

I would expect the debugger to require a forward reference for these methods and data members ...

You are correct, and your suggestion matches what Visual Studio produces. I fixed the patch to match this behavior.

[rnk]

llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp

803–804

These comments and method names don't make sense anymore, though. We can't actually produce unique names for internal types, it's impossible without some kind of per-TU GUID.

I think this code would be a lot less confusing if we rename this to something more mechanical like getTypeIdentifier. CodeView needs identifiers for all C++ types, even if the names aren't unique and might collide across TUs. For DWARF, we only use identifiers if we have a unique C++ mangled name. The comment should say something about that.

Does that make sense?

[bwyma]

I think this code would be a lot less confusing if we rename this to something more mechanical like getTypeIdentifier

I changed the routine names, updated the call sites, and made the comment changes.
Please let me know if you like this better.

[rnk]

lgtm, thanks!

[dblaikie]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

Just came across this code today - it's /probably/ a problem for LTO. LLVM IR linking depends on the identifier to determine if two structs are the same for linkage purposes - so if an identifier is added for a non-linkage (local/not externally visible) type, LLVM will consider them to be the same even though they're unrelated:

namespace { struct t1 { int i; int j; }; }
t1 v1;
void *v3 = &v1;

namespace { struct t1 { int i; }; }
t1 v1;
void *v2 = &v1;

$ clang++-tot -emit-llvm -S a.cpp b.cpp -g -gcodeview  && ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep "\"t1\""
!8 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "t1", scope: !9, file: !3, line: 1, size: 64, flags: DIFlagTypePassByValue, elements: !10, identifier: "_ZTSN12_GLOBAL__N_12t1E")
$ clang++-tot -emit-llvm -S a.cpp b.cpp -g && ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep "\"t1\""
!8 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "t1", scope: !9, file: !3, line: 1, size: 64, flags: DIFlagTypePassByValue, elements: !10)
!21 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "t1", scope: !9, file: !17, line: 1, size: 32, flags: DIFlagTypePassByValue, elements: !22)

So in linking, now both a.cpp and b.cpp refer to a single t1 type (in this case, it looks like the first one - the 64 bit wide one).

If CodeView actually can't represent these two distinct types with the same name in the same object file, so be it? But this looks like it's likely to cause problems for consumers/users.

[rnk]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

If you use the MSVC ABI, we will assign unique identifiers to these two structs:

!9 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "t1", scope: !10, file: !7, line: 1, size: 64, flags: DIFlagTypePassByValue, elements: !11, identifier: ".?AUt1@?A0xF964240C@@")

The A0xF964240C is set up here, and it is based on the source file path (the hash will only be unique when source file paths are unique across the build):
https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/MicrosoftMangle.cpp#L464

// It's important to make the mangled names unique because, when CodeView
// debug info is in use, the debugger uses mangled type names to distinguish
// between otherwise identically named types in anonymous namespaces.

Maybe this should use a "is MSVC ABI" check instead, since that is what controls whether the identifier will be unique, and the unique-ness is what matters for LTO and PDBs.

[rnk]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

After thinking about it some more, see the comment I added here: rG59320fc9d78237a5f9fdd6a5030d6554bb6976ce

// If the type is not externally visible, it should be unique to the current TU,
// and should not need an identifier to participate in type deduplication.
// However, when emitting CodeView, the format internally uses these
// unique type name identifers for references between debug info. For example,
// the method of a class in an anonymous namespace uses the identifer to refer
// to its parent class. The Microsoft C++ ABI attempts to provide unique names
// for such types, so when emitting CodeView, always use identifiers for C++
// types. This may create problems when attempting to emit CodeView when the MS
// C++ ABI is not in use.

I think type identifiers are pretty crucial for CodeView functionality. The debugger won't be able to link a method to its class without them. Therefore, I think it's better to leave this as it is. The bad experience of duplicate type identifiers is better than the lack of functionality from not emitting identifiers at all for non-externally visible types.

[dblaikie]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

Yeah, thanks for explaining/adding the comment - that about covers it.

Hmm, do these identifiers just need to only be unique within a single object file to provide the name referencing mechanics? Perhaps we could generate them later to ensure they're unique - rather than risk collapsing them while linking?

(at least here's an obscure case where they seem to collide: Compiling the same file with different -D values, I guess the hash is only for the filename, not for other properties that might impact the output - so this ends up with two types with the same mangled name even on MSVC ABI:

namespace { struct t1 { int i;
#ifdef SECOND
  int j;
#endif
}; }
t1 v1;
void*
#ifdef SECOND
v2
#else
v3
#endif
= &v1;

clang++-tot -emit-llvm -S a.cpp -g -gcodeview  -target x86_64-windows && clang++-tot -emit-llvm -S a.cpp -DSECOND -g -gcodeview -o b.ll -target x86_64-windows && ~/dev/llvm/build/default/bin/llvm-link -o ab.bc a.ll b.ll && ~/dev/llvm/build/default/bin/llvm-dis ab.bc && cat ab.ll | grep "\"t1\""

)

[bwyma]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

As Reid already noted, the unique id is required in CodeView to match type definitions to forward references. Unfortunately, the unique id must align across translation units. Compiling the same file multiple times with preprocessor conditionals will result in two different types with the same unique id. You'll see the same behavior with Visual Studio 2019.

[dblaikie]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

I think what I was getting at is that in the case of mangled names for internal linkage things - presumably there's no ABI compatibility concern? It's not like something compiled with MSVC or another version of Clang has to use the same naming scheme for these local entities, so long as the naming scheme doesn't collide?

So at least for LTO if we generated the name later (in the CodeView backend) it could be more unique - an LTO build wouldn't collapse the two types together. It could still have an identifier (generated by the CodeView backend) that was used to reference decls and defs within that file.

[rnk]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

Yes, we could calculate the unique identifier during LTO. However, that seems like a very marginal improvement in the final user experience since most users don't use LTO for incremental development, which is when type information is most useful.

On the other hand, if we want to establish the invariant that all DICompositeType identifiers are unique within a compile unit, we could probably go ahead and do that without impacting the user experience. We already have renaming logic like this for llvm::GlobalValues, and frontends are check for existing values of that name if they don't want renaming to occur.

[dblaikie]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

if we want to establish the invariant that all DICompositeType identifiers are unique within a compile unit, we could probably go ahead and do that without impacting the user experience. We already have renaming logic like this for llvm::GlobalValues, and frontends are check for existing values of that name if they don't want renaming to occur.

That invariant exists - that's the original purpose of the identifiers - LLVM IR linking deduplicates on the basis of the identifier. So we can't/don't rename them (because the point is to deduplicate based on them) - we keep the first one we see and drop the rest.

Any idea what happens when non-LTO with MSVC and you end up with duplicate identifiers? Are both versions kept, but references end up ambiguous? Is the second version seen dropped as being a duplicate/unneeded?

If non-LTO MSVC behavior drops later instances of the identifier as duplicate, then at least the current LTO behavior is no worse than that - though there'd be some opportunity to make at least LTO better, but yeah, marginally beneficial.

[rnk]

lib/CodeGen/CGDebugInfo.cpp

812–814 ↗

(On Diff #147988)

Yes, the linker only retains one complete type definition for each unique type name, so you would get the same behavior with or without LTO.

llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp

static bool hasCXXMangling(const TagDecl *TD, llvm::DICompileUnit *TheCU) {
   case llvm::dwarf::DW_LANG_C_plus_plus:
     return true;
   case llvm::dwarf::DW_LANG_ObjC_plus_plus:
     return isa<CXXRecordDecl>(TD) || isa<EnumDecl>(TD);
   default:
     return false;
   }
 }
 
-/// In C++ mode, types have linkage, so we can rely on the ODR and
-/// on their mangled names, if they're external.
-static SmallString<256> getUniqueTagTypeName(const TagType *Ty,
-                                             CodeGenModule &CGM,
-                                             llvm::DICompileUnit *TheCU) {
-  SmallString<256> FullName;
+// Determines if the tag declaration will require a type identifier.
+static bool needsTypeIdentifier(const TagDecl *TD,
+                                CodeGenModule& CGM,
+  // We only add a type identifier for types with C++ name mangling.
+  if (!hasCXXMangling(TD, TheCU))
+    return false;
+
+  // CodeView types with C++ mangling need a type identifier.
+  if (CGM.getCodeGenOpts().EmitCodeView)
+    return true;
+
+  // Externally visible types with C++ mangling need a type identifier.
+  if (TD->isExternallyVisible())
+    return true;
+
+  return false;
+}
+
+// When emitting CodeView debug information we need to produce a type
+// identifier for all types which have a C++ mangling.  Until a GUID is added
+// to the identifier (not currently implemented) the result will not be unique
+// across compilation units.
+// When emitting DWARF debug information, we need to produce a type identifier
+// for all externally visible types with C++ name mangling. This identifier
+// should be unique across ODR-compliant compilation units.
+static SmallString<256> getTypeIdentifier(const TagType *Ty,
+                                          CodeGenModule &CGM,
+                                          llvm::DICompileUnit *TheCU) {
+  SmallString<256> Identifier;
   const TagDecl *TD = Ty->getDecl();
 
-  if (!hasCXXMangling(TD, TheCU) || !TD->isExternallyVisible())
-    return FullName;
+  if (!needsTypeIdentifier(TD, CGM, TheCU))
+    return Identifier;
 
   // TODO: This is using the RTTI name. Is there a better way to get
   // a unique string for a type?
-  llvm::raw_svector_ostream Out(FullName);
+  llvm::raw_svector_ostream Out(Identifier);
   CGM.getCXXABI().getMangleContext().mangleCXXRTTIName(QualType(Ty, 0), Out);
-  return FullName;
+  return Identifier;
 }
 
 /// \return the appropriate DWARF tag for a composite type.
 static llvm::dwarf::Tag getTagForRecord(const RecordDecl *RD) {
    llvm::dwarf::Tag Tag;
   if (RD->isStruct() || RD->isInterface())
     Tag = llvm::dwarf::DW_TAG_structure_type;
   else if (RD->isUnion())
CGDebugInfo::getOrCreateRecordFwdDecl(const RecordType *Ty,
   llvm::DIFile *DefUnit = getOrCreateFile(RD->getLocation());
   unsigned Line = getLineNumber(RD->getLocation());
   StringRef RDName = getClassName(RD);
 
   uint64_t Size = 0;
   uint32_t Align = 0;
 
   // Create the type.
-  SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
+  SmallString<256> Identifier = getTypeIdentifier(Ty, CGM, TheCU);
   llvm::DICompositeType *RetTy = DBuilder.createReplaceableCompositeType(
       getTagForRecord(RD), RDName, Ctx, DefUnit, Line, 0, Size, Align,
-      llvm::DINode::FlagFwdDecl, FullName);
+      llvm::DINode::FlagFwdDecl, Identifier);
   if (CGM.getCodeGenOpts().DebugFwdTemplateParams)
     if (auto *TSpecial = dyn_cast<ClassTemplateSpecializationDecl>(RD))
       DBuilder.replaceArrays(RetTy, llvm::DINodeArray(),
                              CollectCXXTemplateParams(TSpecial, DefUnit));
   ReplaceMap.emplace_back(
       std::piecewise_construct, std::make_tuple(Ty),
       std::make_tuple(static_cast<llvm::Metadata *>(RetTy)));
   return RetTy;
llvm::DIType *CGDebugInfo::CreateEnumType(const EnumType *Ty) {
 
   uint64_t Size = 0;
   uint32_t Align = 0;
   if (!ED->getTypeForDecl()->isIncompleteType()) {
     Size = CGM.getContext().getTypeSize(ED->getTypeForDecl());
     Align = getDeclAlignIfRequired(ED, CGM.getContext());
   }
 
-  SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
+  SmallString<256> Identifier = getTypeIdentifier(Ty, CGM, TheCU);
 
   bool isImportedFromModule =
       DebugTypeExtRefs && ED->isFromASTFile() && ED->getDefinition();
 
   // If this is just a forward declaration, construct an appropriately
   // marked node and just return it.
   if (isImportedFromModule || !ED->getDefinition()) {
     // Note that it is possible for enums to be created as part of
     // their own declcontext. In this case a FwdDecl will be created
     // twice. This doesn't cause a problem because both FwdDecls are
     // entered into the ReplaceMap: finalize() will replace the first
     // FwdDecl with the second and then replace the second with
     // complete type.
     llvm::DIScope *EDContext = getDeclContextDescriptor(ED);
     llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
     llvm::TempDIScope TmpContext(DBuilder.createReplaceableCompositeType(
         llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit, 0));
 
     unsigned Line = getLineNumber(ED->getLocation());
     StringRef EDName = ED->getName();
     llvm::DIType *RetTy = DBuilder.createReplaceableCompositeType(
         llvm::dwarf::DW_TAG_enumeration_type, EDName, EDContext, DefUnit, Line,
-        0, Size, Align, llvm::DINode::FlagFwdDecl, FullName);
+        0, Size, Align, llvm::DINode::FlagFwdDecl, Identifier);
 
     ReplaceMap.emplace_back(
         std::piecewise_construct, std::make_tuple(Ty),
         std::make_tuple(static_cast<llvm::Metadata *>(RetTy)));
     return RetTy;
   }
 
   return CreateTypeDefinition(Ty);
 }
 
 llvm::DIType *CGDebugInfo::CreateTypeDefinition(const EnumType *Ty) {
   const EnumDecl *ED = Ty->getDecl();
   uint64_t Size = 0;
   uint32_t Align = 0;
   if (!ED->getTypeForDecl()->isIncompleteType()) {
     Size = CGM.getContext().getTypeSize(ED->getTypeForDecl());
     Align = getDeclAlignIfRequired(ED, CGM.getContext());
   }
 
-  SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
+  SmallString<256> Identifier = getTypeIdentifier(Ty, CGM, TheCU);
 
   // Create elements for each enumerator.
   SmallVector<llvm::Metadata *, 16> Enumerators;
   ED = ED->getDefinition();
   bool IsSigned = ED->getIntegerType()->isSignedIntegerType();
   for (const auto *Enum : ED->enumerators()) {
     const auto &InitVal = Enum->getInitVal();
     auto Value = IsSigned ? InitVal.getSExtValue() : InitVal.getZExtValue();
     Enumerators.push_back(
         DBuilder.createEnumerator(Enum->getName(), Value, !IsSigned));
   }
 
   // Return a CompositeType for the enum itself.
   llvm::DINodeArray EltArray = DBuilder.getOrCreateArray(Enumerators);
 
   llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
   unsigned Line = getLineNumber(ED->getLocation());
   llvm::DIScope *EnumContext = getDeclContextDescriptor(ED);
   llvm::DIType *ClassTy = getOrCreateType(ED->getIntegerType(), DefUnit);
   return DBuilder.createEnumerationType(EnumContext, ED->getName(), DefUnit,
                                         Line, Size, Align, EltArray, ClassTy,
-                                        FullName, ED->isFixed());
+                                        Identifier, ED->isFixed());
 }
 
 llvm::DIMacro *CGDebugInfo::CreateMacro(llvm::DIMacroFile *Parent,
                                         unsigned MType, SourceLocation LineLoc,
                                         StringRef Name, StringRef Value) {
   unsigned Line = LineLoc.isInvalid() ? 0 : getLineNumber(LineLoc);
   return DBuilder.createMacro(Parent, Line, MType, Name, Value);
 }
llvm::DICompositeType *CGDebugInfo::CreateLimitedType(const RecordType *Ty) {
   // appropriately marked node and just return it.
   const RecordDecl *D = RD->getDefinition();
   if (!D || !D->isCompleteDefinition())
     return getOrCreateRecordFwdDecl(Ty, RDContext);
 
   uint64_t Size = CGM.getContext().getTypeSize(Ty);
   auto Align = getDeclAlignIfRequired(D, CGM.getContext());
 
-  SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
+  SmallString<256> Identifier = getTypeIdentifier(Ty, CGM, TheCU);
 
   // Explicitly record the calling convention for C++ records.
   auto Flags = llvm::DINode::FlagZero;
   if (auto CXXRD = dyn_cast<CXXRecordDecl>(RD)) {
     if (CGM.getCXXABI().getRecordArgABI(CXXRD) == CGCXXABI::RAA_Indirect)
       Flags |= llvm::DINode::FlagTypePassByReference;
     else
       Flags |= llvm::DINode::FlagTypePassByValue;
   }
 
   llvm::DICompositeType *RealDecl = DBuilder.createReplaceableCompositeType(
       getTagForRecord(RD), RDName, RDContext, DefUnit, Line, 0, Size, Align,
-      Flags, FullName);
+      Flags, Identifier);
 
   // Elements of composite types usually have back to the type, creating
   // uniquing cycles.  Distinct nodes are more efficient.
   switch (RealDecl->getTag()) {
   default:
     llvm_unreachable("invalid composite type tag");
 
   case llvm::dwarf::DW_TAG_array_type:
   case llvm::dwarf::DW_TAG_enumeration_type:
     // Array elements and most enumeration elements don't have back references,
     // so they don't tend to be involved in uniquing cycles and there is some
     // chance of merging them when linking together two modules.  Only make
     // them distinct if they are ODR-uniqued.
-    if (FullName.empty())
+    if (Identifier.empty())
       break;
     LLVM_FALLTHROUGH;
 
   case llvm::dwarf::DW_TAG_structure_type:
   case llvm::dwarf::DW_TAG_union_type:
   case llvm::dwarf::DW_TAG_class_type:
     // Immediately resolve to a distinct node.
     RealDecl =

llvm/tools/clang/test/CodeGen/debug-info-codeview-unnamed.c

+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -debug-info-kind=limited -S -emit-llvm -o - %s | FileCheck --check-prefix LINUX %s
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited -gcodeview -S -emit-llvm -o - %s | FileCheck --check-prefix MSVC %s
+
+int main(int argc, char* argv[], char* arge[]) {
+
+  // In both DWARF and CodeView, an unnamed C structure type will generate a
+  // DICompositeType without a name or identifier attribute;
+  //
+  struct { int bar; } one = {42};
+  //
+  // LINUX:      !{{[0-9]+}} = !DILocalVariable(name: "one"
+  // LINUX-SAME:     type: [[TYPE_OF_ONE:![0-9]+]]
+  // LINUX-SAME:     )
+  // LINUX:      [[TYPE_OF_ONE]] = distinct !DICompositeType(
+  // LINUX-SAME:     tag: DW_TAG_structure_type
+  // LINUX-NOT:      name:
+  // LINUX-NOT:      identifier:
+  // LINUX-SAME:     )
+  //
+  // MSVC:       !{{[0-9]+}} = !DILocalVariable(name: "one"
+  // MSVC-SAME:      type: [[TYPE_OF_ONE:![0-9]+]]
+  // MSVC-SAME:      )
+  // MSVC:       [[TYPE_OF_ONE]] = distinct !DICompositeType
+  // MSVC-SAME:      tag: DW_TAG_structure_type
+  // MSVC-NOT:       name:
+  // MSVC-NOT:       identifier:
+  // MSVC-SAME:      )
+
+  return 0;
+}

llvm/tools/clang/test/CodeGenCXX/debug-info-codeview-unnamed.cpp

+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -debug-info-kind=limited -S -emit-llvm -std=c++11 -o - %s | FileCheck --check-prefix LINUX %s
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited -gcodeview -S -emit-llvm -std=c++11 -o - %s | FileCheck --check-prefix MSVC %s
+
+int main(int argc, char* argv[], char* arge[]) {
+  //
+  // In CodeView, the LF_MFUNCTION entry for "bar()" refers to the forward
+  // reference of the unnamed struct. Visual Studio requires a unique
+  // identifier to match the LF_STRUCTURE forward reference to the definition.
+  //
+  struct { void bar() {} } one;
+  //
+  // LINUX:      !{{[0-9]+}} = !DILocalVariable(name: "one"
+  // LINUX-SAME:     type: [[TYPE_OF_ONE:![0-9]+]]
+  // LINUX-SAME:     )
+  // LINUX:      [[TYPE_OF_ONE]] = distinct !DICompositeType(
+  // LINUX-SAME:     tag: DW_TAG_structure_type
+  // LINUX-NOT:      name:
+  // LINUX-NOT:      identifier:
+  // LINUX-SAME:     )
+  //
+  // MSVC:       !{{[0-9]+}} = !DILocalVariable(name: "one"
+  // MSVC-SAME:      type: [[TYPE_OF_ONE:![0-9]+]]
+  // MSVC-SAME:      )
+  // MSVC:       [[TYPE_OF_ONE]] = distinct !DICompositeType
+  // MSVC-SAME:      tag: DW_TAG_structure_type
+  // MSVC-SAME:      name: "<unnamed-type-one>"
+  // MSVC-SAME:      identifier: ".?AU<unnamed-type-one>@?1??main@@9@"
+  // MSVC-SAME:      )
+
+
+  // In CodeView, the LF_POINTER entry for "ptr2unnamed" refers to the forward
+  // reference of the unnamed struct. Visual Studio requires a unique
+  // identifier to match the LF_STRUCTURE forward reference to the definition.
+  //
+  struct { int bar; } two = { 42 };
+  int decltype(two)::*ptr2unnamed = &decltype(two)::bar;
+  //
+  // LINUX:      !{{[0-9]+}} = !DILocalVariable(name: "two"
+  // LINUX-SAME:     type: [[TYPE_OF_TWO:![0-9]+]]
+  // LINUX-SAME:     )
+  // LINUX:      [[TYPE_OF_TWO]] = distinct !DICompositeType(
+  // LINUX-SAME:     tag: DW_TAG_structure_type
+  // LINUX-NOT:      name:
+  // LINUX-NOT:      identifier:
+  // LINUX-SAME:     )
+  //
+  // MSVC:       !{{[0-9]+}} = !DILocalVariable(name: "two"
+  // MSVC-SAME:      type: [[TYPE_OF_TWO:![0-9]+]]
+  // MSVC-SAME:      )
+  // MSVC:       [[TYPE_OF_TWO]] = distinct !DICompositeType
+  // MSVC-SAME:      tag: DW_TAG_structure_type
+  // MSVC-SAME:      name: "<unnamed-type-two>"
+  // MSVC-SAME:      identifier: ".?AU<unnamed-type-two>@?2??main@@9@"
+  // MSVC-SAME:      )
+
+
+  // In DWARF, named structures which are not externally visibile do not
+  // require an identifier.  In CodeView, named structures are given an
+  // identifier.
+  //
+  struct named { int bar; int named::* p2mem; } three = { 42, &named::bar };
+  //
+  // LINUX:      !{{[0-9]+}} = !DILocalVariable(name: "three"
+  // LINUX-SAME:     type: [[TYPE_OF_THREE:![0-9]+]]
+  // LINUX-SAME:     )
+  // LINUX:      [[TYPE_OF_THREE]] = distinct !DICompositeType(
+  // LINUX-SAME:     tag: DW_TAG_structure_type
+  // LINUX-SAME:     name: "named"
+  // LINUX-NOT:      identifier:
+  // LINUX-SAME:     )
+  //
+  // MSVC:       !{{[0-9]+}} = !DILocalVariable(name: "three"
+  // MSVC-SAME:      type: [[TYPE_OF_THREE:![0-9]+]]
+  // MSVC-SAME:      )
+  // MSVC:       [[TYPE_OF_THREE]] = distinct !DICompositeType
+  // MSVC-SAME:      tag: DW_TAG_structure_type
+  // MSVC-SAME:      name: "named"
+  // MSVC-SAME:      identifier: ".?AUnamed@?1??main@@9@"
+  // MSVC-SAME:      )
+
+
+  // In CodeView, the LF_MFUNCTION entry for the lambda "operator()" routine
+  // refers to the forward reference of the unnamed LF_CLASS for the lambda.
+  // Visual Studio requires a unique identifier to match the forward reference
+  // of the LF_CLASS to its definition.
+  //
+  auto four = [argc](int i) -> int { return argc == i ? 1 : 0; };
+  //
+  // LINUX:      !{{[0-9]+}} = !DILocalVariable(name: "four"
+  // LINUX-SAME:     type: [[TYPE_OF_FOUR:![0-9]+]]
+  // LINUX-SAME:     )
+  // LINUX:      [[TYPE_OF_FOUR]] = distinct !DICompositeType(
+  // LINUX-SAME:     tag: DW_TAG_class_type
+  // LINUX-NOT:      name:
+  // LINUX-NOT:      identifier:
+  // LINUX-SAME:     )
+  //
+  // MSVC:       !{{[0-9]+}} = !DILocalVariable(name: "four"
+  // MSVC-SAME:      type: [[TYPE_OF_FOUR:![0-9]+]]
+  // MSVC-SAME:      )
+  // MSVC:       [[TYPE_OF_FOUR]] = distinct !DICompositeType
+  // MSVC-SAME:      tag: DW_TAG_class_type
+  // MSVC-NOT:       name:
+  // MSVC-SAME:      identifier: ".?AV<lambda_0>@?0??main@@9@"
+  // MSVC-SAME:      )
+
+  return 0;
+}