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.
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:
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.