Cannot parse `func.func`

[Blaine Rister]

Hi,

First of all, thank you for the excellent package.

I think I ran into a corner case with your parser logic. The rule for func does not seem to recognize func.func. This is supported in the most recent versions of MLIR, as func is now an operator of the func dialect. (In fact, I believe bare func no longer works in MLIR.) See this test case:

import mlir

ast3 = mlir.parse_string('''
module {
  func.func @toy_func(%tensor: tensor<2x3xf64>) -> tensor<3x2xf64> {
    %t_tensor = "toy.transpose"(%tensor) { inplace = true } : (tensor<2x3xf64>) -> tensor<3x2xf64>
    return %t_tensor : tensor<3x2xf64>
  }
}
''')

On the latest version I get:

  File "/venv/lib/python3.10/site-packages/mlir/parser.py", line 133, in parse_string
    return parser.parse(code)
  File "/venv/lib/python3.10/site-packages/mlir/parser.py", line 93, in parse
    tree = self.parser.parse(code)
  File "/venv/lib/python3.10/site-packages/lark/lark.py", line 581, in parse
    return self.parser.parse(text, start=start, on_error=on_error)
  File "/venv/lib/python3.10/site-packages/lark/parser_frontends.py", line 106, in parse
    return self.parser.parse(stream, chosen_start, **kw)
  File "/venv/lib/python3.10/site-packages/lark/parsers/earley.py", line 297, in parse
    to_scan = self._parse(lexer, columns, to_scan, start_symbol)
  File "/venv/lib/python3.10/site-packages/lark/parsers/xearley.py", line 144, in _parse
    to_scan = scan(i, to_scan)
  File "/venv/lib/python3.10/site-packages/lark/parsers/xearley.py", line 118, in scan
    raise UnexpectedCharacters(stream, i, text_line, text_column, {item.expect.name for item in to_scan},
lark.exceptions.UnexpectedCharacters: No terminal matches '@' in the current parser context, at line 3 col 13

  func.func @toy_func(%tensor: tensor<2x3xf64>) -> t
            ^
Expected one of: 
        * ESCAPED_STRING
        * __ANON_4
        * PERCENT
        * COLON
        * __ANON_8
        * __ANON_10
        * DOT
        * __ANON_1
        * __ANON_7
        * __ANON_9
        * FALSE
        * __ANON_0
        * TRUE

I think this should be a simple fix. Happy to contribute a PR.

[Tal Ben-Nun]

Thank you for reporting this. It's due to the recent change in MLIR where builtins also belong to dialects. The func dialect now has its own syntactic sugar that is not supported in pyMLIR and should be easy to support.

We'll be happy to accept a pull request.

Alternatively, you can use the generic op syntax to parse the code, see https://github.com/spcl/pymlir/#instructions

[Blaine Rister]

Sure, I will prepare a PR to move the relevant builtins into the func dialect.

[Blaine Rister]

Please see the PR here: #20