This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
>>> Operation.parse('"arith.addi"() : () -> ()')) Traceback (most recent call last): File "<stdin>", line 1, in <module> mlir._mlir_libs.MLIRError: Unable to parse operation assembly: error: "-":1:1: 'arith.addi' op requires one result note: "-":1:1: see current operation: "arith.addi"() : () -> ()
The diagnostic information is available on the exception for users who
may want to customize the error message:
>>> try: ... Operation.parse('"arith.addi"() : () -> ()') ... except MLIRError as e: ... print(e.message) ... print(e.error_diagnostics) ... print(e.error_diagnostics[0].message) ... Unable to parse operation assembly [<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>] 'arith.addi' op requires one result
Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
emit_error_diagnostics option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.
API changes:
- Operation.verify now raises an exception on verification failure, instead of returning false
- The exception raised by the following methods has been changed to MLIRError:
- PassManager.run
- {Module,Operation,Type,Attribute}.parse
- {RankedTensorType,UnrankedTensorType}.get
- {MemRefType,UnrankedMemRefType}.get
- VectorType.get
- FloatAttr.get
closes #60595
I couldn't find a way to define an exception with custom __init__ through pybind, so it's defined in python + imported here. Another option would be to use the C API.