[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