Attribute names

I see generated functions for attribute names, which are non-static. Is there a reason against generating these as static functions? This would be useful for custom builders or implementing the type inference interface.

I see multiple places in the code base working around this, e.g. in mlir/IR/FunctionInterfaces.h where attribute names like function_type are listed again.

Is the return type for these StringRef or StringAttr? We try to avoid string manipulation as much as possible and many generated methods are here to cache StringAttr in the context.

The type is StringAttr so it makes sense to have it in the context. I see how this is desirable to avoid string manipulations.

Also, I just saw that there is a static version of the function that expects the OperationName as an additional argument, so technically it is possible to do something like this.

OperationName op_name(SomeOp::getOperationName(), ctx);
Attribute attr = attributes.get(SomeOp::some_attrAttrName(op_name));

You know the internals better than I do, so would you consider this the way to do it?
If so, we should probably generate a convenient function for this. It seems to be a somewhat common use case that is currently mostly worked around by redefining the attribute name as a constant somewhere.

I may be missing something, but attributes.get("AttrName"); should just work here?

Right, that works but is that not an anti-pattern? It defines the attribute name in a second place (besides the td file), which is prone to errors.

So basically you’re thinking about providing static StringRef getAttrName() { return "AttrName"; } so that as call site we’d write attributes.get(SomeOp::getAttrName()); instead of attributes.get("AttrName"); , and the benefit is that we get compile time checking for the attribute name?

Yes, exactly that

Turns out this can be done nicely with the adaptors