[clang] Do not print locations in anonymous tag names. (PR #159592)

[David Blaikie via cfe-commits]

dwblaikie wrote:

> Hi @dwblaikie
> 
> > Also - maybe compare to GCC's naming? (could be nice to converge, but I'm not sure that's possible/might be in tension with matching demangling)
> 
> We actually did compare to what GCC does, and you can see with this [compiler explorer link](https://godbolt.org/z/b6K43oazb) that GCC doesn't add the location to the DW_AT_name cc @Michael137 for the example (thanks for providing that!)

*nod* So GCC does make some extra effort to make these things a bit more unique by including the scope (though it fails for the inline variable - I /think/ they should be scoped to the inline variable too, since the type does have an ODR/linkage name, the lambdas should be deduplicable across translation units, etc) and the argument types (wonder how that works if the argument types are template parameters... that can get complicated (hmm, "tfunc<<lambda(auto:1)> >" it seems, for a basic case)): https://godbolt.org/z/ThsY6hco9
```
template <typename T>
void tfunc(const T&) {}
inline void x() {
    tfunc([] {});       // tfunc<x()::<lambda()> >
    tfunc([] {});       // tfunc<x()::<lambda()> >
    tfunc([](int) {});  // tfunc<x()::<lambda(int)> >
}
inline int i = (tfunc([] {}),       // tfunc<<lambda()> >
                tfunc([] {}),       // tfunc<<lambda()> >
                tfunc([](int) {}),  // tfunc<<lambda(int)> >
                1);
void y() {
    x();
    (void)i;
    tfunc([] {});       // tfunc<y()::<lambda()> >
    tfunc([] {});       // tfunc<y()::<lambda()> >
    tfunc([](int) {});  // tfunc<y()::<lambda(int)> >
}
```

It'd be nice to do at least that, but I'd argue we should do a bit more - by including the mangling number in them too.

> > Oh, and did you hit some particular problem with this varied naming situation? It's not immediately obvious to me that this would be a problem
> 
> Yes, we had an issue with dsymutil, we saw varifiction error in the DWARFVerifier when trying to verify the contents of the Accelerator tables. Since dsymutil does type uniquing similar to LTO.

Ah, alrighty. New verification checks you're working on/adding, I take it? Good to know/hear about/commendable - I'm sure it's a lot of little things to track down/try to fix, but should make the DWARF more robust/reliable/deterministic/expected.

> > Any chance we could use a naming that matches/is similar to the mangling? Including the lambda numbering - could help ensure the names are unique-ish?
> 
> Correct me if I am wrong, but if we use the mangling, whats the difference between the DW_AT_name and the DW_AT_linkage_name?

Ideally, not much should be different, imho. Eventually we should/could ask the question of whether the linkage name is redundant (ideally the linkage name would be the one we remove, though I realize that places a fairly substantial burden on consumers to reconstruct names in a non-trivial way - but the upside is that DWARF descriptions have a lot of redundancy elimination in them (structurally, think about an exponential template expansion "T<T<T<>, T<>>, T<T<>, T<>>>" - DWARF contains no duplication itself in the structural description - with simplified template names it contains no duplication in the DW_AT_name, and the mangled name can only deduplicate within itself - not across names (so in the DWARF where you have the linkage name for "T<>", and for "T<T<>, T<>>" and for the outer "T<...>" there's no ability for the latter to reuse the former - but the DWARF references back to those other DIEs just fine))).

(@rnk for FYI on this thread in general, and some ideas here)

But even without that somewhat fanciful future world without linkage names in DWARF - notionally the DW_AT_name is a name fragment that's immediately usable without demangling, etc. So I think it still makes sense to include a name that might match the demangling (most simple names do - we include the name of function "foo" despite the fact it's identical to the name you could get from demangling, even in more complex template examples that's often still true) and it seems important to end users that they have a good chance at identifying which lambda is being referenced - which means having /at least/ as much uniqueness as the mangling. And I agree with you that it's important that names don't have /more/ uniqueness than the mangling.

So the conclusion that it should have /exactly as much/ uniqueness as the mangling - which, to me, pushes pretty close to printing out something pretty close to identical to the demangling (note, I think there are demanglings that aren't unique - where multiple mangled names demangle to the same name - so perhaps even with the demangling matching motivation we might not quite reach the "have at least as much uniqueness as the mangling" property I described above)

https://github.com/llvm/llvm-project/pull/159592