[test] como doesn't like #warning
This from the regression results for como- 4_3_3- vc7_1: "G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h ^ -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:43A44CF4.7000408@boost-consulting.com...
This from the regression results for como- 4_3_3- vc7_1:
"G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h ^
How did we manage to get into this branch? Gennadiy
Eric Niebler wrote:
This from the regression results for como- 4_3_3- vc7_1:
"G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h ^
This warning is present on Tru64/CXX for ages now. See http://comments.gmane.org/gmane.comp.lib.boost.devel/126154 for reference. I would greatly appreciate if it disappeared... Markus
Markus Schöpflin wrote:
Eric Niebler wrote:
This from the regression results for como- 4_3_3- vc7_1:
"G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or # include Boost.Test header in front of winbase.h ^
This warning is present on Tru64/CXX for ages now. See http://comments.gmane.org/gmane.comp.lib.boost.devel/126154 for reference. I would greatly appreciate if it disappeared...
Something like: #ifdef BOOST_PP_HAS_WARNINGS #warning foo bar #endif where BOOST_PP_HAS_WARNINGS is defined in boost/config/compiler/gcc.hpp ? Or, given the proposed rewrite of the config stuff have the macro defined to 0 for all compilers except gcc and use as #if BOOST_PP_HAS_WARNINGS Angus
Angus Leeming wrote:
Something like:
#ifdef BOOST_PP_HAS_WARNINGS #warning foo bar #endif
where BOOST_PP_HAS_WARNINGS is defined in boost/config/compiler/gcc.hpp
?
Or, given the proposed rewrite of the config stuff have the macro defined to 0 for all compilers except gcc and use as #if BOOST_PP_HAS_WARNINGS
I don't think this will help, because the preprocessor seems to scan the whole file. ---%<--- #if 0 #foo #endif --->%---
cxx -c -std strict_ansi foo.cc cxx: Warning: foo.cc, line 2: unrecognized preprocessing directive #foo -^
Markus
Markus Schöpflin wrote:
Angus Leeming wrote:
Something like:
#ifdef BOOST_PP_HAS_WARNINGS #warning foo bar #endif
where BOOST_PP_HAS_WARNINGS is defined in boost/config/compiler/gcc.hpp
?
Or, given the proposed rewrite of the config stuff have the macro defined to 0 for all compilers except gcc and use as #if BOOST_PP_HAS_WARNINGS
I don't think this will help, because the preprocessor seems to scan the whole file.
Interesting. We've used that solution for ever with LyX and I never had a problem with my (admittedly old) version of DEC's cxx. That machine is now history however. Presumably, therefore, the solution is to define BOOST_WARNING(text) which expands to nothing with all compilers except gcc for which it expands to #warning text. Angus
Angus Leeming wrote:
Markus Schöpflin wrote:
I don't think this will help, because the preprocessor seems to scan the whole file.
Interesting. We've used that solution for ever with LyX and I never had a problem with my (admittedly old) version of DEC's cxx. That machine is now history however.
I bet you don't use -std strict_ansi, or do you?
Presumably, therefore, the solution is to define BOOST_WARNING(text) which expands to nothing with all compilers except gcc for which it expands to #warning text.
If this works, that would be great. Markus
Angus Leeming wrote:
Presumably, therefore, the solution is to define BOOST_WARNING(text) which expands to nothing with all compilers except gcc for which it expands to #warning text.
If this works, that would be great.
Macros expanding to a preprocessor directive result in undefined behaviour. Regards Hartmut
Markus Schöpflin wrote:
Interesting. We've used that solution for ever with LyX and I never had a problem with my (admittedly old) version of DEC's cxx. That machine is now history however.
I bet you don't use -std strict_ansi, or do you?
Of course! But as I say this was an old machine with an old (2002) version of cxx. Perhaps you should ascertain what the preprocessor experts here think the preprocessor should do with this. Maybe cxx is wrong? #if 0 #unknown_command foo #endif Angus
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Angus Leeming
Perhaps you should ascertain what the preprocessor experts here think the preprocessor should do with this. Maybe cxx is wrong?
#if 0 #unknown_command foo #endif
It's wrong. That's not an error. Regards, Paul Mensonides
Paul Mensonides wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Angus Leeming
Perhaps you should ascertain what the preprocessor experts here think the preprocessor should do with this. Maybe cxx is wrong?
#if 0 #unknown_command foo #endif
It's wrong. That's not an error.
So if I understand you correctly, it should just skip over any gibberish it might encounter until the matching #endif is found? Is the preprocessor allowed to issue warnings about the gibberish? Markus
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Markus Schöpflin
#if 0 #unknown_command foo #endif
It's wrong. That's not an error.
So if I understand you correctly, it should just skip over any gibberish it might encounter until the matching #endif is found?
Yes, except that it still must tokenize the block. You can still get errors in tokenization, such as: #if 0 "half-open // error #endif
Is the preprocessor allowed to issue warnings about the gibberish?
The main point about the above is that the block must be tokenized, but it should not be parsed to produce directives or scanned for macro replacement. It is theoretically allowed to issue warnings about anything--just like the rest of the compiler. Warnings are a QOI issue, though it isn't very high quality to issue warnings about code inside unused conditional compilation blocks. Regards, Paul Mensonides
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Mensonides
So if I understand you correctly, it should just skip over any gibberish it might encounter until the matching #endif is found?
Yes, except that it still must tokenize the block. You can still get errors in tokenization, such as:
#if 0 "half-open // error #endif
Is the preprocessor allowed to issue warnings about the gibberish?
The main point about the above is that the block must be tokenized, but it should not be parsed to produce directives or scanned for macro replacement.
What I said here isn't quite correct, so I'll elaborate. The block has to be parsed just enough to determine nested conditional compilation blocks. E.g. #if 0 #if 0 #endif #endif ...but it isn't supposed to parse anything else--including an operands to directives. So, the following should still work: #if 0 #if // no expression! #endif #endif So, basically, the only parse is to tell if a name following '#' on a new line is one of the conditional compilation directives or not. Specifically, from 16.1/6, "...the group that it controls is skipped: directives are processed only through the name that determines the directive in order to keep track of the level of nested conditionals; the rest of the directives' preprocessing tokens are ignored, as are the other preprocessing tokens in the group." Regards, Paul Mensonides
Paul Mensonides wrote:
What I said here isn't quite correct, so I'll elaborate. The block has to be parsed just enough to determine nested conditional compilation blocks. E.g.
#if 0 #if 0 #endif #endif
....but it isn't supposed to parse anything else--including an operands to directives. So, the following should still work:
#if 0 #if // no expression! #endif #endif
So, basically, the only parse is to tell if a name following '#' on a new line is one of the conditional compilation directives or not. Specifically, from 16.1/6, "...the group that it controls is skipped: directives are processed only through the name that determines the directive in order to keep track of the level of nested conditionals; the rest of the directives' preprocessing tokens are ignored, as are the other preprocessing tokens in the group."
Ok, thanks for elaborating. I think this gives me enough details to file a bug report with the compiler vendor. Markus
"Markus Schöpflin" <markus.schoepflin@comsoft.de> wrote in message news:do5vga$akt$1@sea.gmane.org...
Eric Niebler wrote:
This from the regression results for como- 4_3_3- vc7_1:
"G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h ^
This warning is present on Tru64/CXX for ages now. See http://comments.gmane.org/gmane.comp.lib.boost.devel/126154 for reference. I would greatly appreciate if it disappeared...
With proper configuration your never supposed to get into this branch. The only reason it's there is because Boost.Build playing with MW(?) config somehow improperly (IMO). Gennadiy
participants (6)
-
Angus Leeming -
Eric Niebler -
Gennadiy Rozental -
Hartmut Kaiser -
Markus Schöpflin -
Paul Mensonides