Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Can you post on discourse that you are looking to add this to std?
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
452 | I would make printing the message a requirement. Instead, how about Optionally, a runtime might use the provided message to print an error. |
Thanks for posting on discourse.
Makes sense to me. We can lower this to our vm.cond_fail pseudo-op (https://github.com/google/iree/blob/bf894c869e281985f392775c0cc0bb199201b477/iree/compiler/Dialect/VM/IR/VMOps.td#L1875), which forget lowers to a cond_br with a vm.fail terminator in the target block.
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
451 | I think the semantics would need to be spelt out. Is execution guaranteed to abort on failure? The next line only talks about the error message printing being optional. |
mlir/test/Dialect/Standard/ops.mlir | ||
---|---|---|
22 | This is inconsistent with the doc description which says the error message is optional. |
mlir/test/Dialect/Standard/ops.mlir | ||
---|---|---|
22 | The error message is required. What the runtime does with it is up to the user though. |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
467 | nit: You don't need to specify this if it is empty. |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
457 | There is no "assert" function. (it's a macro; see my post on discourse). I think we should just remove this line from the description. |
Update documentation
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
453 | I always found line breaks after sentences more semantic, they lead to more readable diffs, and prevent line fragmentation when the text is changed. |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
453 | Yes please. Keeping consistency with the rest of the file and project comment style is important. We have been following "regular" writing practices wrt lines vs sentences vs paragraph as one is optimising for the reader and not for changes/diffing (where tools do a good job with highlighting already and changing isn't the common case). Inconsistencies/deviations make readers wonder about the significance and impairs reading. Of course if there is a discussion where we adopt a new documentation convention, then this may change. |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
453 | Will keep this in mind and corrected the documentation in a separate CL. |
I think the semantics would need to be spelt out. Is execution guaranteed to abort on failure? The next line only talks about the error message printing being optional.