diff options
author | Matthias Springer <me@m-sp.org> | 2025-04-09 17:49:47 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-04-09 17:49:47 +0200 |
commit | a00a61d59bf1c1f142c8e08b74a0f26991122f7a (patch) | |
tree | 1b04e483e728e1f8ee74287208a29a420cd8fe3b /llvm/lib/Transforms/Utils/CloneFunction.cpp | |
parent | 9344b2196cbc36cdc577314bbb2b889606ba6820 (diff) | |
download | llvm-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