While I am trying to forbid such usages systematically in https://reviews.llvm.org/D79427 / P2166R0 to C++ standard, this PR fixes this (definitelly incorrect) usage in llvm.
This code is unreachable, so it could not cause any harm
Differential D87697
Do not construct std::string from nullptr georgthegreat on Sep 15 2020, 7:49 AM. Authored by
Details While I am trying to forbid such usages systematically in https://reviews.llvm.org/D79427 / P2166R0 to C++ standard, this PR fixes this (definitelly incorrect) usage in llvm. This code is unreachable, so it could not cause any harm
Diff Detail
Event TimelineComment Actions I would rather see: llvm_unreachable("unexpected type"); return ""; // or string() i.e, keep the call to unreachable.
Comment Actions I'd split the difference and keep the unreachable but drop the return - llvm_unreachable is annotated noreturn and all the compilers we use for LLVM are OK with/don't warn on: "non_void f1() { llvm_unreachable(...); }" As for the possibility of relying on a switch with a default, where all cases and the default return or call a no-return function. I'd be OK with that, if it works for all the compilers LLVM supports - if there's prior art/examples of this in the LLVM codebase, that'd be adequate for me. & yeah, I'd be OK with @mclow.lists 's suggestion to move the default to the end and just have it break, keeping a singular unreachable (& though I'd favor fairly strongly not having a return after that) outside the switch. Comment Actions Changed as dblaikie@ suggested. Not all the types are handled during the switch, so default is still required in order to prevent compiler from issuing warnings. Comment Actions Good for me - please wait for @mclow.lists to weigh in/close the loop as well, though. |
@mclow.lists There already is a call to llvm_unreachable here ^ so the second call to unreachable seems redundant.