Open smeenai opened 1 week ago
Using lists of fused locs isn't great indeed (unpacking it will always be a guess game), one example is the IfOp which right now might have a list of 4 locs (to track begin/end for both arms), we kinda infer what's that about. As you rightly pointed out, to do this right we need some layer of abstraction in the likely form of a new attribute.
As discussed in https://github.com/llvm/llvm-project/pull/113483, if we see a future need for it (e.g. for debug information or diagnostics), we can consider including more information in the
mlir::Location
s we create, e.g. to capture macro expansion information. We could potentially use an OpaqueLoc attribute for this that includes the original SourceLocation or create our own location attribute that wraps a clang SourceLocation (if we need full serialization/deserialization). There's no action needed here right now, I'm just creating this for tracking.