aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/CloneFunction.cpp
diff options
context:
space:
mode:
authorMatthias Springer <me@m-sp.org>2025-04-09 17:49:47 +0200
committerGitHub <noreply@github.com>2025-04-09 17:49:47 +0200
commita00a61d59bf1c1f142c8e08b74a0f26991122f7a (patch)
tree1b04e483e728e1f8ee74287208a29a420cd8fe3b /llvm/lib/Transforms/Utils/CloneFunction.cpp
parent9344b2196cbc36cdc577314bbb2b889606ba6820 (diff)
downloadllvm-a00a61d59bf1c1f142c8e08b74a0f26991122f7a.zip
llvm-a00a61d59bf1c1f142c8e08b74a0f26991122f7a.tar.gz
llvm-a00a61d59bf1c1f142c8e08b74a0f26991122f7a.tar.bz2
[mlir][IR] Improve error message when parsing incorrect type (#134984)
Improve error messages when parsing an incorrect type. Before: ``` invalid kind of type specified ``` After: ``` invalid kind of type specified: expected builtin.tensor, but found 'tensor<*xi32>' ``` This error message is produced when a certain operand/result type is expected according to an op's TableGen definition, but a different type is parsed. Type constraints (which may have nice error messages) are checked after parsing a type. If an incorrect type is parsed, we never get to the point of printing type constraint error messages. This may discourage users from specifying C++ classes with type constraints. (Explicitly specifying C++ classes is beneficial because the auto-generated C++ code will have richer type information; explicit casts are unnecessary, etc.) See #134981 for an example where specifying additional type information with type constraints (e.g., `LLVM_AnyVector`) lead to worse error messages. Note: In order to generate a better error message, the parser must retrieve a type's name from the C++ class. TableGen-generated type classes always have a `name` field, but hand-written C++ type classes may not. The `HasStaticName` template was copied from `DialectImplementation.h` (`HasStaticDialectName`).
Diffstat (limited to 'llvm/lib/Transforms/Utils/CloneFunction.cpp')
0 files changed, 0 insertions, 0 deletions