[llvm] [DebugInfo] Merge partially matching chains of textual inclusions (PR #125780)

[Vladislav Dzhidzhoev via llvm-commits]

dzhidzhoev wrote:

> > This patch has nothing to do with "full textual-inclusion call stack". The goal here is to preserve as much information as possible when merging locations. I think Anton meant that nested DILexicalBlocks attributed to different files have structure similar to inlinedAt-location chains.
> 
> Alright, that's in line with my initial assumptions about the goal of the patch. So going back to my first comment, is there a need to generalize the location-merging logic? We shouldn't need to produce a full stack of nested DILexicalBlockFiles, because only the immediately containing file of the merged DILocations matters for the debug info consumer. If we get a non-line-0 location, then it will have the correct file as long as we check that the file scope for the merged lines match and use the matching file; if we get a line-0 location, then it doesn't matter what the file is (we can just fall back to the file scope of the containing DISubprogram). In either case, the chain of DILexicalBlockFiles won't be visible and as far as I can tell doesn't need to be produced - is this correct, or am I missing something either in general or about your particular use case?

If I understand your initial comment correctly, your idea means that we get a line-0 location if L1 and L2 from a `getMergedLocation(L1, L2)` call belong to different files even though there is an "include site" they have in common Am I right?
With the approach in this commit, we're trying to find a "common include location" and use it for the locations from different files. Such resulting location should be visible for a debugger.

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