[Mlir-commits] [mlir] [mlir][linalg] Fix `SemiFunctionType` custom parsing crash on missing `()` (PR #110365)

Felix Schneider llvmlistbot at llvm.org
Tue Oct 22 11:23:58 PDT 2024


================
@@ -12,9 +12,13 @@
 using namespace mlir;
 
 ParseResult mlir::parseSemiFunctionType(OpAsmParser &parser, Type &argumentType,
-                                        Type &resultType) {
+                                        Type &resultType, bool resultOptional) {
   argumentType = resultType = nullptr;
-  bool hasLParen = parser.parseOptionalLParen().succeeded();
+
+  bool hasLParen = resultOptional ? parser.parseOptionalLParen().succeeded()
+                                  : parser.parseLParen().succeeded();
+  if (!resultOptional && !hasLParen)
+    return failure();
   if (parser.parseType(argumentType).failed())
     return failure();
   if (!hasLParen)
----------------
ubfx wrote:

This causes problems for Ops with exactly one non optional result, like `transform.structured.generalize`. We could write an invalid version of such an op like this:
```mlir
transform.structured.generalize %arg0 : !transform.any_op
```
This would successfully go through your parser because it looks like a valid `SemiFunctionType` with optional or no results. However, this will then lead to a crash during Op creation, because `resultType` is never initialized, yet it is not optional.
In general, if we have a non-optional result, we always either have to fail within the parser, or we have to correctly read the result's Type. Without the `resultOptional` argument enforcing the reading of the result, we can have ops slip through the cracks by using the form without parens and result Types.

https://github.com/llvm/llvm-project/pull/110365


More information about the Mlir-commits mailing list