Add basic support for registering diagnostic handlers with the context
(actually, the diagnostic engine contained in the context) and processing
diagnostic messages from the C API.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks - this will be very helpful.
Nits and one question about API stability.
mlir/include/mlir-c/Support.h | ||
---|---|---|
61 | How likely do you think it will be that this will change? At an API boundary like this with inline functions, even though insulated behind a function call, it would be quite a chaotic thing to change it (ie. Existing binaries interpreting true values as false). If this is a serious possibility to flip semantics, better to take the optimization hit and make the accessors opaque. On the other hand, this seems like a totally fine thing for the C API to specify completely and disallow future change: if the underlying implementation changes semantics, the C API layer would translate to the compatible semantics. | |
74 | Did you mean to lowercase the leasing "m"? | |
mlir/test/CAPI/ir.c | ||
1017 | Typo in "CHEKC" |
mlir/include/mlir-c/Support.h | ||
---|---|---|
61 | I don't expect this to change, but also don't want users to inspect things directly. But it's C, so direct inspection is probably unavoidable, so we may just use an enum instead. WDYT? |
mlir/include/mlir-c/Support.h | ||
---|---|---|
61 | It's C - the best you can do is provide a speed bump. I'm fine with how you have it, but I think you should remove the part of the comment about this changing: in fact we need a string guarantee that it doesn't change, and it is put together this way for legibility. |
mlir/include/mlir-c/Support.h | ||
---|---|---|
61 | I removed that part of the comment. Just for completeness, here how the enum solution would look like - https://reviews.llvm.org/D88960. It would allow for if (someOperation())-style checks, which is what LogicalResult was expected to solve. |
How likely do you think it will be that this will change? At an API boundary like this with inline functions, even though insulated behind a function call, it would be quite a chaotic thing to change it (ie. Existing binaries interpreting true values as false). If this is a serious possibility to flip semantics, better to take the optimization hit and make the accessors opaque.
On the other hand, this seems like a totally fine thing for the C API to specify completely and disallow future change: if the underlying implementation changes semantics, the C API layer would translate to the compatible semantics.