| Age | Commit message (Collapse) | Author |
|---|
|
...of 87369ad7b82da6904e889614c88617e610d4506b "Use std::unreachable if
available". (Unfortunately, Clang didn't warn about the thus meaningless uses
of O3TL_UNREACHABLE, presumably due to
<https://github.com/llvm/llvm-project/commit/978cca9f49a1c0e3a01096017c9a34726866fbf3>
"Suppress all -Wunused-value warnings from macro body expansions.")
(While at it, and as the expansion of O3TL_UNREACHABLE is now a nice full
expression, wrap it in parentheses, as is common best practice for such macro
definitions.)
Change-Id: I555e6716ebb66172add686521446d90db6054845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130729
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I686e36cf3e77a94293ef6923ba00181eb3e02c81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130661
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The code in sw/source/core/fields/reffld.cxx had turned into whack-a-mole: MSVC
needed the unreachable default:assert(false); to fall through to init some vars
to avoid C4701 ("potentially uninitialized local variable"). But Clang (with
!NDEBUG, and an implementation of assert marked as noreturn) reported that as
"fallthrough annotation in unreachable code", requiring the #ifdef NDEBUG guards
to be added. And now clang-cl (also with !NDEBUG, but with the MSVC
implementation of assert apparently not marked as noreturn) complained about
"unannotated fall-through between switch labels", which wold require the #ifdef
NDEBUG guards to be removed again.
O3TL_UNREACHABLE (inspired by LLVM's llvm_unreachable and underyling
LLVM_BUILTIN_UNREACHABLE) hopefully improves on that for all compilers involved.
For non-MSVC (i.e., Clang or GCC) it assumes that __builtin_unreachable is
supported (which it is at least for GCC 7, which is our current baseline per
README.md).
Change-Id: I4474f95664d97c3d0e506bab90f80d5ab252ec6e
Reviewed-on: https://gerrit.libreoffice.org/67232
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
