Michael137 wrote: Thanks for the additional context. The reason I was asking is that `CGDebugInfo` use the `clang::TypePrinter` to emit `DW_AT_name`s. That's not ideal because the two might not be aligned in the way that types should be printed. This shows particularly in this situation, where we want the entire scope of the entity to be reflected in the name, whereas Clang omits things like the function that we're scoped in. Admittedly there is the `PrintingPolicy` that allows us to customise the printing, but it's getting a bit fiddly. But hoping to get it to work with the `TypePrinter` for now. I don't think we want to be moving away from it.
> > Agreed with Shubham that I'll take this one forward. > > Do I understand correctly that we somewhat settled on the way forward being > > to print into `DW_AT_name` the full scope of the anonymous lambda > > (including the lambda number), so we have an unambiguous name for it? > > Something along those lines, yes - the specific spelling, etc, I don't think > we settled on. It could be identical to the mangling, or could be different - > so long as it is exactly as unique as the mangling: no more, no less. Right, pretty much "scope + unique-ish name (as far as the mangling allows)" > > If we do want to stop relying on source locations, how do we deal with > > unnamed structures? Those don't have an equivalent to lambda numbering > > (that I know of). > > They do, actually, though GCC and Clang don't have to agree on the mangling, > since these entities have internal linkage. > > > So something like ([godbolt](https://godbolt.org/z/sWs1YMxov)): Ahh right! Yea that makes sense. Thankfully `MangleNumberingContext` should encapsulate that all for us. So we should be able to treat lambdas and unnamed records the same way. > > So do we just also align with GCC here and "give up" on a unique name for > > unnamed structures? > > I don't think so - I think it's still valuable to have unique names - it's > not /as/ important for internal linkage entities, because they don't need to > be name-associated between CUs (ThinLTO notwithstanding... ). Sounds good > So even if we get exactly-unique-enough names, if those names are based on > lambda numbering, we wouldn't be able to classify the names as > reconstitutable until we add that lambda numbering to the DWARF structural > description of the type in such a way that we can reproduce the name again > (which might mean more than just the numbering - ie, we'd need to know how to > differentiate `f2()::{unnamed type#1}` from `f1()::$_1` when rebuilding the > name/trying to differentiate two types, just knowing it's anonymous thing > number 1 wouldn't be sufficient. Ah fair point. https://github.com/llvm/llvm-project/pull/159592 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
