[Mlir-commits] [mlir] [mlir][AsmParser] Fix parseOptionalAttribute consuming loc() as an attribute (PR #180668)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Wed Feb 11 18:00:51 PST 2026
XiaoleiShi-NV wrote:
> Overall, I think this is going in the right direction. But there is now a discrepancy between `parseOptionalAttribute` and `parseAttribute`. If we remove `Token::kw_loc` from `parseOptionalAttribute`, we should also remove it from `parseAttribute`.
@matthias-springer Thanks for the review! You raise a good point about the discrepancy.
Removing `Token::kw_loc` from `parseAttribute` as well would mean `loc(...)` is no longer parseable as an inline attribute value. This would affect:
- Attribute dictionary values: `{foo.loc_attr = loc(unknown)}`
- Required `LocationAttr` op arguments: `test.op_with_loc_attr loc("loc1":10:20)`
- Tests in `mlir/test/IR/locations.mlir` (lines 33-43, 110-112)
The printer side (`AsmPrinter.cpp:2553`) currently prints `LocationAttr` attribute values using `printLocation`, which outputs the `loc(...)` syntax. So removing from `parseAttribute` without updating the printer would break roundtripping.
Making this fully consistent would require changing how `LocationAttr` is printed/parsed when it appears as an attribute value -- likely through the dialect attribute mechanism instead of the `loc(...)` keyword syntax. That's a larger MLIR syntax change.
Would you prefer:
1. Expanding this PR to handle the full `parseAttribute` removal (plus printer changes and test updates), or
2. Keeping this PR scoped to the `parseOptionalAttribute` fix?
I'll address the test dialect feedback in the meantime.
https://github.com/llvm/llvm-project/pull/180668
More information about the Mlir-commits
mailing list