[Mlir-commits] [mlir] [mlir] Add FileRange location type. (PR #80213)

[Jacques Pienaar]

================
@@ -102,6 +102,44 @@ def FileLineColLoc : Builtin_LocationAttr<"FileLineColLoc"> {
   let attrName = "builtin.file_line_loc";
 }
 
+//===----------------------------------------------------------------------===//
+// FileRange
+//===----------------------------------------------------------------------===//
+
+def FileRangeLoc : Builtin_LocationAttr<"FileRangeLoc"> {
+  let summary = "A file:line:column to line:column source location range";
+  let description = [{
+    Syntax:
+
+    ```
+    filelinecol-location ::= `range(` string-literal `:` integer-literal `:`
+                             integer-literal ` to ` integer-literal `)`
+    ```
+
+    An instance of this location represents a tuple of file, start line number,
+    start column number, end line, and end column number. This represents a range
+    inside a file.
+  }];
+  let parameters = (ins "StringAttr":$filename, "unsigned":$line,
+                        "unsigned":$column, "unsigned":$byte_size);
----------------
jpienaar wrote:

Yes that's in the PR description

> In particular storing the end line and end column in addition or instead of size. But storing both results in encoding redundant info and wasn't sure the visual benefit in the non-sourgemanager case is worth it. And storing these instead would result in less efficient error emission

For user facting tools, you would be using the SourceMgr or something else (probably a language level equivalent of SourceMgr like clang does) indeed and being able to query these. This output is for the plain command line testing tools/compiler devs.

Now the option of just using offsets for both and start is there or, as you mention, start offset + size is there. It would differ from FileLocation reporting & difficult for users to find start. So the reason I am proposing hybrid, is that it would be as useful as FileLocation for basic tools users while enabling the reporting as range for user facing tools without any redudant encoding. 

 > This would require the tool to query the SourceMgr (if one is available) for the line/column of the end position, which could result in incorrect column numbers if there are multibyte characters and no information about the file's text encoding is known.

The file encoding doesn't change does it? So if the size is computed from the file, then the reporting using the same assumption as during coding should produce same range.

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