The C-API supports consuming errors, converting an error to a string error
message, and querying an error's type. Other LLVM C APIs that wish to use
llvm::Error can supply error-type-id checkers and custom
error-to-structured-type converters for any custom errors they provide.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
It seems to me this will not handle multi-error objects correctly, but I don't know much about your use case to know whether that is an issue or not.
include/llvm/Support/Error.h | ||
---|---|---|
1191 ↗ | (On Diff #160608) | In case Err contains more than one error message, this will preserve just the last one. Are you worried about that? |
lib/Support/Error.cpp | ||
132 ↗ | (On Diff #160608) | Any chance LLVMErrorTypeId could be a const void * (to avoid the const cast)? |
I think I can make a partial fix for this bug, but honestly I have been uncomfortable with the builtin compound error for a long time. I wasn't planning to support it via the C API initially, and I'm wondering whether we should not remove it entirely and force people to build their own custom compound errors.
lib/Support/Error.cpp | ||
---|---|---|
132 ↗ | (On Diff #160608) | Absolutely. I forgot we don't have to support ancient C compilers. :) |
Fixed support for wrapping and unwrapping compound errors, and made LLVMErrorTypeId
const per labeth's suggestion.
I am not sure my LGTM is enough, but in any case, it looks good to me.
BTW, I too have sometimes felt that the built-in ErrorList handling was sometimes too magical.