[mlir] tblgen no member named 'getValue' in 'mlir::OptionalParseResult'

[tschuett]

llvm-project/mlir/tools/mlir-tblgen/AttrOrTypeDefGen.cpp

Line 738 in fb447e7

if (::mlir::succeeded(parseResult.getValue()))

: error: no member named 'getValue' in 'mlir::OptionalParseResult'
      if (::mlir::succeeded(parseResult.getValue()))

Thanks and follow up issue :-(

[llvmbot]

@llvm/issue-subscribers-mlir

[tschuett]

I believe this:

llvm-project/mlir/tools/mlir-tblgen/AttrOrTypeDefGen.cpp

Line 740 in 06bb948

return Type();

should mlir::Type().

[joker-eph]

Thanks! Fixed in a6a7a1b

[J-MR-T]

llvm-project/mlir/tools/mlir-tblgen/AttrOrTypeDefGen.cpp

Line 738 in fb447e7

if (::mlir::succeeded(parseResult.getValue()))

: error: no member named 'getValue' in 'mlir::OptionalParseResult'
      if (::mlir::succeeded(parseResult.getValue()))

Thanks and follow up issue :-(

I have the same issue, when trying to make my dialect extensible (let isExtensible = 1).

Manually going in the tblgen-generated .inc file and changing the line

if (::mlir::succeeded(parseResult.getValue()))

to

if (::mlir::succeeded(parseResult.value()))

solves the issue. Could somebody with commit privileges change this here, @joker-eph perhaps? I don't know the proper process for contributing to LLVM and currently haven't got the time to figure it out. Also, I think a more thorough test of extensible dialects (TestDialect doesn't seem to catch this issue) to prevent this from happening again might be good, but I fully understand that's a bit much to ask.

[joker-eph]

Also, I think a more thorough test of extensible dialects (TestDialect doesn't seem to catch this issue) to prevent this from happening again might be good,

The TestDialect is extensible, but unfortunately this particular combination also requires let useDefaultTypePrinterParser = 1; and the test dialect has let useDefaultTypePrinterParser = 0;...

[joker-eph]

@J-MR-T if you can confirm that 87a1421 fixes your issue?