$ cat test.cpp #pragma GCC diagnostic ignored "-Wc++0x-compat" namespace std { class nullptr_t { }; } extern std::nullptr_t nullptr; $ g++ -Wc++0x-compat -c test.cpp test.cpp:5:1: warning: identifier ‘nullptr’ will become a keyword in C++0x [-Wc++0x-compat] $ g++ -Wc++0x-compat -Werror -c test.cpp test.cpp:5:1: error: identifier ‘nullptr’ will become a keyword in C++0x [-Werror=c++0x-compat] cc1plus: all warnings being treated as errors
Confirmed.
So far have been able to figure out that diagnostic_classify_diagnostic apparently sets correctly context->n_classification_history to 1 when the pragma is parsed, but then is found == 0 in diagnostic_report_diagnostic.
It seems, the warning is emitted *before* the pragma is actually processed in diagnostic_classify_diagnostic...
We are Code::Blocks' developers, we see the same annoying warnings, hope it will be fixed. Thanks. See: http://forums.codeblocks.org/index.php/topic,16670.msg113169.html#msg113169
(In reply to comment #4) > We are Code::Blocks' developers, we see the same annoying warnings, hope it > will be fixed. Thanks. > See: > http://forums.codeblocks.org/index.php/topic,16670.msg113169.html#msg113169 Sorry, I post a wrong link, the link is only accessed by C::B developers, so it is a private link. But we just discuss the same issue.
Confirmed present in GCC 4.7.1 g++ foo.cpp -Wall -std=c++98 our use case is that we have a code base in transition to C++0x and have created our own nullptr_t for the platform that have not yet transitioned to C++0x we would like to acknowledge/suppress this warning in the file that implements the nullptr_t without resorting to -Wno-c++0x-compat on the commmand line. --Roger
Additional workaround (big hammer) #pragma GCC system_header Best used when the code generating the warning is in an isolated header file --Roger
Indeed, handle_pragma_diagnostic is called too late after lexing because pragmas are only parsed during the parsing phase but warnings can be emitted way earlier (and even earlier than lexing, during command-line setup). Bah, this doesn't look easy to fix at all.
If this warning is given by the preprocessor during lexing, then this is a dup of bug 53431.
(In reply to Manuel López-Ibáñez from comment #9) > If this warning is given by the preprocessor during lexing, then this is a > dup of bug 53431. It is. *** This bug has been marked as a duplicate of bug 53431 ***