-Wunreachable-code warnings can no longer be suppressed?

I suppressed a -Wunreachable-code warning in Firefox earlier this year [1] by adding extra parentheses, as suggested by Xcode's clang on OS X:

objdir-osx/dom/bindings/TestJSImplGenBinding.cpp:47639:20: note: silence by adding parentheses to mark code as explicitly dead
        if (false && !CallerSubsumes(temp)) {
                     ^
                     /* DISABLES CODE */ ()

This is generated C++ code in Firefox, so changing the code generator to emit the extra parentheses was easier than complicating the code generator's logic for this particular case.

Unfortunately, this Firefox warning is back [2] because clang 3.9 on Linux no longer recognizes the parentheses suppression. Is this an intentional change to -Wunreachable-code or a regression? I don't see the warning string "silence by adding parentheses to mark code as explicitly dead" in the clang code on GitHub [3], but I see a few clang tests that appear to expect that warning string.

thanks,
chris

[1] 1223265 - Fix -Wunreachable-code and -Wimplicit-fallthrough warnings in dom/bindings and dom/ipc
[2] 1291397 - obj/dom/bindings/TestCodeGenBinding.cpp:6236:7: error: code will never be executed [-Werror,-Wunreachable-code], due to "if ((false) &&...)" in generated source code
[3] GitHub - llvm-mirror/clang: Mirror kept for legacy. Moved to https://github.com/llvm/llvm-project

The string is here: https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/DiagnosticSemaKinds.td#L499

Should still work. Nearest I could test seems to:

Thanks for testing, David. Below is a standalone test case that reproduces the insuppressible warning even with Xcode’s clang (Apple LLVM version 7.3.0 (clang-703.0.31)). So there is a latent clang bug plus a regression that caused Firefox’s previously-suppressible warning to no longer be suppressible. The warning looks like it might only happen when the boolean condition involves an expression with a templated type. In the test case below, a templated local variable gets copy-constructed to form an argument to a boolean helper-function. I filed clang bug 28918 for this issue: $ clang++ -Wunreachable-code test.cpp test.cpp:23:5: warning: code will never be executed [-Wunreachable-code] printf(“Does clang warn about this code being unreachable?\n”); ^~~~~~ 1 warning generated. thanks, chris // Compile me like so: // clang++ -Wunreachable-code test.cpp // and see if I produce a build warning. // // Note that if you change aSomeVec to be a non-templated type, then // the build warning goes away. #include “stdio.h” #include // Note: aSomeVec must be passed by value to trigger the problem, it seems. // Changing to std::vector& reference silences the warning. static bool FuncThatTakesATemplatedArg(std::vector /* aSomeVec */) { return false; } int main() { std::vector myVec; if ((false) && !FuncThatTakesATemplatedArg(myVec)) { printf(“Does clang warn about this code being unreachable?\n”); return 1; } return 0; }