Macros that expand into multiple terms can cause interesting preprocessor hickups depending
on the context they are used in. https://github.com/llvm/llvm-project/issues/56867 reported
a miscompilation of llvm_unreachable(msg) inside a LLVM_DEBUG({ ... }) block. We were
able to fix it by wrapping the expansion in a do {} while(false).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Please find more details on the diagnosis here https://github.com/llvm/llvm-project/issues/56867#issuecomment-1205190498
llvm/include/llvm/Support/ErrorHandling.h | ||
---|---|---|
152 | One might argue that macros should always expand into the same expression type. Not sure it's necessary here, but of course we could apply this change to the other cases as well. Let me know if you think it would be better. |
llvm/include/llvm/Support/ErrorHandling.h | ||
---|---|---|
150–154 | This is improperly formatted, please use clang-format. |
llvm/include/llvm/Support/ErrorHandling.h | ||
---|---|---|
150–154 | Right, clang-format want's this: do { \ LLVM_BUILTIN_TRAP; \ LLVM_BUILTIN_UNREACHABLE; \ } while (false) I choose not to follow it in my patch, because the existing code is only 6 months old and didn't respect clang-format. Instead I mimicked the style of the LLVM_DEBUG macro which expands into a similar do-while construct: https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Debug.h#L64 Of course, I can change that if there are good reasons or strong opinions on it. |
llvm/include/llvm/Support/ErrorHandling.h | ||
---|---|---|
150–154 | Imagine that the 6-month old change followed the style. It would save your time on deciding whether to clang-format it or not. Formatting it properly now will save people time when modifying this file in the future. This is the whole purpose of the style guide -- saving time on choosing the right formatting. |
llvm/include/llvm/Support/ErrorHandling.h | ||
---|---|---|
150–154 | FYI: I find the clang-format version much more readable, it's not clear to me why we shouldn't just adopt it. |
One might argue that macros should always expand into the same expression type. Not sure it's necessary here, but of course we could apply this change to the other cases as well. Let me know if you think it would be better.