[llvm-bugs] [Bug 151896] [MLIR] custom in Symbol's assemblyFormat generates call to non-member versions of parseSymbolName and printSymbolName

[LLVM Bugs via llvm-bugs]

Issue	151896
Summary	[MLIR] custom<SymbolName> in Symbol's assemblyFormat generates call to non-member versions of parseSymbolName and printSymbolName
Labels	mlir
Assignees
Reporter	xushengj

    version: `llvmorg-20.1.8`

When I made the following Op definition: (`AssetDeclarationOp` has `Symbol` trait)
```
def ImageAssetOp : AssetDeclarationOp<"image_asset", []> {
  ...
  let assemblyFormat = "custom<SymbolName>($sym_name) $asset_id `,` $imageattrs attr-dict `:` type($result)";
}
```

Tablegen emits the following code in `cpp.inc` that calls non-member version of parseSymbolName and printSymbolName:
```
::mlir::ParseResult ImageAssetOp::parse(::mlir::OpAsmParser &parser, ::mlir::OperationState &result) {
  ::mlir::StringAttr sym_nameAttr;
  ...
  {
    auto odsResult = parseSymbolName(parser, sym_nameAttr);
    ...
  }
 ...
}
...
void ImageAssetOp::print(::mlir::OpAsmPrinter &_odsPrinter) {
 _odsPrinter << ' ';
  printSymbolName(_odsPrinter, *this, getSymNameAttr());
  ...
}
```

However, in `mlir/IR/OpImplementation.h`, they are member functions of `AsmParser` and `AsmPrinter`, respectively, which causes the compilation to fail. I currently use the following workaround: (i.e., define non-member versions of the functions)

```
namespace mlir::preppipe::PrepPipe {
llvm::ParseResult parseSymbolName(AsmParser &parser,
 StringAttr &result) {
  return parser.parseSymbolName(result);
}
void printSymbolName(AsmPrinter &printer, Operation *op,
 StringAttr symName) {
  printer.printSymbolName(symName);
}
} // end namespace mlir::preppipe::PrepPipe

#define GET_OP_CLASSES
#include "preppipe-mlir/Dialect/PrepPipe/IR/PrepPipeOps.cpp.inc"
```

_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs