Append LocationAttr to the operations

[oovm]

Appending location information can help with error reporting.

I suggest using the form of file-id + start-offset

struct LocationAttr {
    file: usize,
    offset: usize
}

For reference, MILR uses string + row + column, but I don't like this format.

First of all, there are a large number of definitions in a file, just use id to index and share them.

The column format actually requires that the internal encoding and the external encoding are the same, otherwise they will be misaligned.

For example, many rust libraries use utf8 columns, but the lsp uses utf16 columns, which will cause inaccurate positioning.

I have been troubled by this problem for a long time.

The byte displacement is independent of encoding and can even act on unknown encodings.

Overall, better results can be achieved with a smaller size.

[vaivaswatha]

Appending location information can help with error reporting.

Yes. I haven't gotten to adding this yet, but will do so soon enough.

For reference, MILR uses string + row + column, but I don't like this format.

MLIR uses StringAttr for the filename. Since MLIR's Attributes are uniqued, this representation is efficient. In the case of pliron, Attributes aren't uniqued (they are more like MLIR's recently introducedPropertys).

I suggest using the form of file-id + start-offset
there are a large number of definitions in a file, just use id to index and share them.

I see your point about using a file-id rather than the filename string everywhere. That's more efficient, given that our attributes aren't uniqued.

The column format actually requires that the internal encoding and the external encoding are the same, otherwise they will be misaligned.
For example, many rust libraries use utf8 columns, but the lsp uses utf16 columns, which will cause inaccurate positioning.

I see your point about using an offset instead of (line, column). But I still think we're better of with (line, column). This is because it may not always be possible to compute the (line, column) pair, which is what we ultimately want to report, from the offset. Doing so requires reading the input file again which may not always be possible (like if the input is stdin, for example). Another reason for me to say this is that the IR parser that I'm working on (based on the combine parser combinator library) reports its position as a line and column pair. That's also what's expected in most language parsers. So users of pliron who translate their source language to our IR will have a difficult time translating their (line, column) to an offset.

[oovm]

Ok, I looked into Parsable, and since the parser itself produces (line, column), this is appropriate.

[vaivaswatha]

Implemented with 4b52e76. Closing.