[Mlir-commits] [mlir] [mlir] Add the ability to define dialect-specific location attrs. (PR #105584)

[Aman LaChapelle]

================
@@ -322,12 +322,19 @@ class AttributeInterface
 // Core AttributeTrait
 //===----------------------------------------------------------------------===//
 
-/// This trait is used to determine if an attribute is mutable or not. It is
-/// attached on an attribute if the corresponding ImplType defines a `mutate`
-/// function with proper signature.
 namespace AttributeTrait {
+/// This trait is used to determine if an attribute is mutable or not. It is
+/// attached on an attribute if the corresponding ConcreteType defines a
+/// `mutate` function with proper signature.
 template <typename ConcreteType>
 using IsMutable = detail::StorageUserTrait::IsMutable<ConcreteType>;
+
+/// This trait is used to determine if an attribute is a location or not. It is
----------------
bzcheeseman wrote:

I think the trade-off is what you just mentioned - it's a little less flexible, but it's also less costly. My major concern was that when parsing, we don't want every location parsed to have to go through interface dispatch, basically.

> but what happens to the API on LocationAttr (e.g. walk?)

Wouldn't the walk just advance into the attribute itself with `walkFn(*this)` up at the top? I could totally be missing something but that was my read. The thought was that if you called `walk` you'd call the generic attribute `walk`, which does the same walk you'd expect from anywhere.

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