[llvm] [Symbolize] Always use filename:line from debug info when debug info for the given address is available. (PR #128619)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> > Feels a bit awkward to add new virtual functions for this - when, at least I think in theory, the new virtual functions are strictly more expressivse than the old ones (so, one option would be to rename the virtual functions to add the new behavior, then add non-virtual wrapping functions that provide the old behavior under the original name).
> > But, also - maybe this isn't the level at which to make the change? Perhaps inside the DILine Info, the file/line number should be wrapped in an optional, so it's clear that neither of those things is present/valid?
> 
> I share this concern, and I think there is already a lot of prior art for expressing ideas like "source" and "confidence level" inside of the DILineInfo struct. What is the meaning of the `IsApproximateLine` boolean, for example? We could freely add another boolean there to indicate our confidence, i.e. the presence of a line table. The callers that currently distinguish success by checking for line 0 would migrate to this boolean.

Switching to bundle the file/line/column/whatever else (source I guess, because no need to carry source if you don't know which file it is in anyway) optional would require more explicit cleanup, but I'd prefer that (the data structure would be more self descriptive/constrained) than adding an extra boolean.

The `IsApproximateLine` attribute is for folks who really don't like line zero - it searches backwards in the line table to find the nearest non-zero entry. It can even cross basic block boundaries, if I recall correctly. It could create confusion in stack frames (could lead the line/file/column to be from the caller (or callee) but outside (or inside) a different inlined subroutine range, etc)

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