[Mlir-commits] [mlir] [mlir] Add concept of alias blocks (PR #65503)
Markus Böck
llvmlistbot at llvm.org
Mon Sep 18 10:43:14 PDT 2023
================
@@ -79,6 +82,9 @@ ParseResult Parser::parseFusedLocation(LocationAttr &loc) {
LocationAttr newLoc;
if (parseLocationInstance(newLoc))
return failure();
+ if (syntaxOnly())
----------------
zero9178 wrote:
I ruled out the deferred aliases approach as not implementable.
The way it works for locations is that a placeholder location is created that is then later RAUW with the actual location at the end of the module.
The reason I don't think is implementable is because todays attributes and types would not be able to handle having some placeholder returned from `parseType` or `parseAttribute` as they tend to check that these are of specific kinds (e.g. `IntegerAttr` or `MemRefElementTypeInterface` or fullfill some other specific constraints.
See also https://discourse.llvm.org/t/rfc-supporting-aliases-in-cyclic-types-and-attributes/73236#return-placeholder-attributes-or-types-10
I agree that this is invasive and I'd love to hear better options. I initially considered writing separate `skipType` and `skipAttr` functions, but there I'd essentially just end up reimplementing the whole parser for the builtin attributes, including error messages, which would lead to a lot of code duplications. Any other way of skipping that isn't based on actually parsing the syntactic elements I'd consider more of a "hack" that is prone to breaking.
The silver lining is that this logic and invasiveness is private to the parser implementation and not user exposed and only part of the *builtin* attribute and type parsing, not any dialect parsing.
https://github.com/llvm/llvm-project/pull/65503
More information about the Mlir-commits
mailing list