[teeks99][test] Test failures on MSVC 8-11
Hi, I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed? [1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html
On Mon, Nov 2, 2015 at 10:34 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Hi,
I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed?
[1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html
I'd be happy to provide more detail, but not sure how to go about that. Any ideas? Tom
On 2015-11-02 22:35, Tom Kent wrote:
On Mon, Nov 2, 2015 at 10:34 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Hi,
I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed?
[1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html
I'd be happy to provide more detail, but not sure how to go about that. Any ideas?
I remember we had similar problems with Boost.Log when the build was terminating due to a timeout. Is it possible that this is also a timeout? I guess, full build/test logs from Boost.Log or Boost.Test could help.
Le 02/11/15 17:34, Andrey Semashev a écrit :
Hi,
I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed?
[1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html
I merged develop to master last Wednesday afternoon, after I checked the status on develop which was ok (topics merged the day before, empty diff between develop and master). The MSVC7.1 column was the only problematic one. I would say there is a problem on the runner side. For the little story, we deployed a specific continuous build for boost.test. For Win we are testing only against VS2013. I will install VS2012 tomorrow on our runners. I am sorry but I cannot do that tonight. Best, Raffi
Le 02/11/15 20:44, Raffi Enficiaud a écrit :
Le 02/11/15 17:34, Andrey Semashev a écrit :
Hi,
I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed?
[1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set-
test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html
I merged develop to master last Wednesday afternoon, after I checked the status on develop which was ok (topics merged the day before, empty diff between develop and master).
The MSVC7.1 column was the only problematic one. I would say there is a problem on the runner side.
For the little story, we deployed a specific continuous build for boost.test. For Win we are testing only against VS2013. I will install VS2012 tomorrow on our runners. I am sorry but I cannot do that tonight.
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing: template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
Those are scoped by #ifndef BOOST_NO_CXX11_AUTO_DECLARATIONS /.../ but apparently this is not enough. Not sure which of the boost.config we should use there. I am now adding MSVC-11 to our runners, and push a hot fix, and still wondering why those columns were green last wednesday. Raffi
On 2015-11-03 00:45, Raffi Enficiaud wrote:
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing:
template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
Those are scoped by
#ifndef BOOST_NO_CXX11_AUTO_DECLARATIONS /.../
but apparently this is not enough.
BOOST_NO_CXX11_AUTO_DECLARATIONS says that the compiler does not support automatic variable type deduction: auto x = 10;
Not sure which of the boost.config we should use there.
You're using a template alias. The BOOST_NO_CXX11_TEMPLATE_ALIASES macro shows that the compiler lacks support for it, and it is defined for MSVC versions older than 12. Boost.Config macros for C++11 features are described here: http://www.boost.org/doc/libs/1_59_0/libs/config/doc/html/boost_config/boost...
I am now adding MSVC-11 to our runners, and push a hot fix, and still wondering why those columns were green last wednesday.
Probably because the tests had not cycled by then?
Le 02/11/15 22:53, Andrey Semashev a écrit :
On 2015-11-03 00:45, Raffi Enficiaud wrote:
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing:
template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
Those are scoped by
#ifndef BOOST_NO_CXX11_AUTO_DECLARATIONS /.../
but apparently this is not enough.
BOOST_NO_CXX11_AUTO_DECLARATIONS says that the compiler does not support automatic variable type deduction:
auto x = 10;
Not sure which of the boost.config we should use there.
You're using a template alias. The BOOST_NO_CXX11_TEMPLATE_ALIASES macro shows that the compiler lacks support for it, and it is defined for MSVC versions older than 12.
Thanks, fixed and testing now.
[snip]
I am now adding MSVC-11 to our runners, and push a hot fix, and still wondering why those columns were green last wednesday.
Probably because the tests had not cycled by then?
I thought I triple checked, my mistake then. I will push to develop and then to master once my runners are green (now including MSVC-11, but nothing under 11 unfortunately). Should be ready in a couple of hours. Raffi
Le 02/11/15 22:53, Andrey Semashev a écrit :
On 2015-11-03 00:45, Raffi Enficiaud wrote:
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing:
template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
[snip] You're using a template alias. The BOOST_NO_CXX11_TEMPLATE_ALIASES macro shows that the compiler lacks support for it, and it is defined for MSVC versions older than 12. [snip]
It's in develop now. I'll merge tomorrow morning to master. Related note: on MSVC-11 (update 5), in bjam "[ require cxx11_trailing_result_types ]" is fulfilled while BOOST_NO_CXX11_TRAILING_RESULT_TYPES is set. Is it because of update 5 of MSVC-11 or is it a known issue on the support of this C++11 feature? Raffi
Le 03/11/15 02:04, Raffi Enficiaud a écrit :
Le 02/11/15 22:53, Andrey Semashev a écrit :
On 2015-11-03 00:45, Raffi Enficiaud wrote:
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing:
template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
[snip] You're using a template alias. The BOOST_NO_CXX11_TEMPLATE_ALIASES macro shows that the compiler lacks support for it, and it is defined for MSVC versions older than 12. [snip]
It's in develop now. I'll merge tomorrow morning to master.
Related note: on MSVC-11 (update 5), in bjam "[ require cxx11_trailing_result_types ]" is fulfilled while BOOST_NO_CXX11_TRAILING_RESULT_TYPES is set. Is it because of update 5 of MSVC-11 or is it a known issue on the support of this C++11 feature?
Merged to master.
On 2015-11-03 09:26, Raffi Enficiaud wrote:
Le 03/11/15 02:04, Raffi Enficiaud a écrit :
Le 02/11/15 22:53, Andrey Semashev a écrit :
On 2015-11-03 00:45, Raffi Enficiaud wrote:
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing:
template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
[snip] You're using a template alias. The BOOST_NO_CXX11_TEMPLATE_ALIASES macro shows that the compiler lacks support for it, and it is defined for MSVC versions older than 12. [snip]
It's in develop now. I'll merge tomorrow morning to master.
Related note: on MSVC-11 (update 5), in bjam "[ require cxx11_trailing_result_types ]" is fulfilled while BOOST_NO_CXX11_TRAILING_RESULT_TYPES is set. Is it because of update 5 of MSVC-11 or is it a known issue on the support of this C++11 feature?
Merged to master.
The tests are still failing on MSVC-8 and 9.
On 2015-11-08 17:30, Andrey Semashev wrote:
On 2015-11-03 09:26, Raffi Enficiaud wrote:
Le 03/11/15 02:04, Raffi Enficiaud a écrit :
Le 02/11/15 22:53, Andrey Semashev a écrit :
On 2015-11-03 00:45, Raffi Enficiaud wrote:
Ok, I lied: I just installed msvc-11 and tested: some lines in boost.test are failing:
template<typename EnumType> using enum_values = unit_test::static_constant< nfp::typed_keyword<std::initializer_list<std::pair<const cstring,EnumType>>, struct enum_values_t>
;
[snip] You're using a template alias. The BOOST_NO_CXX11_TEMPLATE_ALIASES macro shows that the compiler lacks support for it, and it is defined for MSVC versions older than 12. [snip]
It's in develop now. I'll merge tomorrow morning to master.
Related note: on MSVC-11 (update 5), in bjam "[ require cxx11_trailing_result_types ]" is fulfilled while BOOST_NO_CXX11_TRAILING_RESULT_TYPES is set. Is it because of update 5 of MSVC-11 or is it a known issue on the support of this C++11 feature?
Merged to master.
The tests are still failing on MSVC-8 and 9.
...and gcc 4.4 in C++11 mode is also broken: http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
Le 08/11/15 15:32, Andrey Semashev a écrit :
[snip]
Merged to master.
The tests are still failing on MSVC-8 and 9.
...and gcc 4.4 in C++11 mode is also broken:
http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
I will have a look... tonight.
On 2015-11-08 17:56, Raffi Enficiaud wrote:
Le 08/11/15 15:32, Andrey Semashev a écrit :
[snip]
Merged to master.
The tests are still failing on MSVC-8 and 9.
...and gcc 4.4 in C++11 mode is also broken:
http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
I will have a look... tonight.
gcc 4.4 is still failing. http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6... qcc 4.4.2 is also failing similarly: http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP... as well as mingw testers hosted by Ion: http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g... http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g... These, I believe, are caused by warnings in Boost.Test. Really, I'm very disappointed by Boost.Test quality lately.
Le 21/11/15 14:35, Andrey Semashev a écrit :
On 2015-11-08 17:56, Raffi Enficiaud wrote:
Le 08/11/15 15:32, Andrey Semashev a écrit :
[snip]
Merged to master.
The tests are still failing on MSVC-8 and 9.
...and gcc 4.4 in C++11 mode is also broken:
http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
I will have a look... tonight.
I didn't lie, I fixed the MSVC issues. Also I asked on how to compile with gcc4.4~c0x, but I got no answer and I do not know where to look.
gcc 4.4 is still failing.
http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
I believe this code is correct: #ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST static std::map<char,char const*> const char_type{{ {'<' , "lt"}, {'>' , "gt"}, {'&' , "amp"}, {'\'', "apos"}, {'"' , "quot"} }}; #else /.../ Maybe I am missing something.
qcc 4.4.2 is also failing similarly:
http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP...
Same error. What am I supposed to do with this log? http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6... or that: http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP... ? Why aren't the runners be able to capture the outputs?
as well as mingw testers hosted by Ion:
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
Maybe because of "-Werror=unused-parameter" ? or maybe this one is hiding something else?
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
and maybe because of "-Werror=sign-compare" ? or again this is hiding something else that was cut off in the report... I believe this is the wrong thing to do for those runners: raising those trivial warnings as errors makes them quite useless and this is a waste of time and resource for everybody. Is boost.test compiling for the end users of those platform? I do not know. Those runners are telling just nothing.
Really, I'm very disappointed by Boost.Test quality lately.
What is the point you are trying to make? On my side, I believe the regression workflow and tools **can and should** be improved (runners cycling more frequently, outputs properly captured, history, no downtime due to some big zip file, better ergonomy, more responsive, etc etc). Raffi
On 2015-11-21 23:54, Raffi Enficiaud wrote:
Le 21/11/15 14:35, Andrey Semashev a écrit :
I didn't lie, I fixed the MSVC issues. Also I asked on how to compile with gcc4.4~c0x, but I got no answer and I do not know where to look.
I didn't see you asking. You can compile with gcc 4.4 in C++11 mode pretty much the same way as you can with newer gcc versions - by adding -std=c++0x or -std=gnu++0x to the command line.
gcc 4.4 is still failing.
http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
I believe this code is correct:
#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST static std::map<char,char const*> const char_type{{ {'<' , "lt"}, {'>' , "gt"}, {'&' , "amp"}, {'\'', "apos"}, {'"' , "quot"} }}; #else /.../
Maybe I am missing something.
You're using unified initialization syntax, which is indicated by BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX. BOOST_NO_CXX11_HDR_INITIALIZER_LIST indicates <initializer_list> header absence. If you use both, like in the code above, then you should be checking both macros.
What am I supposed to do with this log? http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
or that: http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP...
?
Why aren't the runners be able to capture the outputs?
Yes, this is a common problem with the current infrastructure. As far as I understand the scripts are not always able to pinpoint the source of failure and as a result the link points to a random console output. Testers do have a full log and upon request on this mailing list may be able to provide it.
as well as mingw testers hosted by Ion:
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
Maybe because of "-Werror=unused-parameter" ? or maybe this one is hiding something else?
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
and maybe because of "-Werror=sign-compare" ? or again this is hiding something else that was cut off in the report...
Nothing is hidden, the command line is shown in the output and it contains -Werror. My point is that these warnings should probably be fixed or silenced.
I believe this is the wrong thing to do for those runners: raising those trivial warnings as errors makes them quite useless and this is a waste of time and resource for everybody.
Is boost.test compiling for the end users of those platform? I do not know. Those runners are telling just nothing.
I've posted links to the concrete build errors, with command lines, isn't that enough? If you see your tests are failing and don't see any meaningful errors in the output, you could at least ask here instead of silently ignoring the failures.
Really, I'm very disappointed by Boost.Test quality lately.
What is the point you are trying to make?
I'm saying that I'm seeing lots of failures caused by Boost.Test in my tests that were passing before for a long time. First caused by inadvertent switch to C++11 only, then the breakage that started this thread. This doesn't help my development.
On my side, I believe the regression workflow and tools **can and should** be improved (runners cycling more frequently, outputs properly captured, history, no downtime due to some big zip file, better ergonomy, more responsive, etc etc).
I'm not happy with regression infrastructure myself, but that's irrelevant to the problems I'm pointing out in this thread.
Le 22/11/15 04:17, Andrey Semashev a écrit :
On 2015-11-21 23:54, Raffi Enficiaud wrote:
Le 21/11/15 14:35, Andrey Semashev a écrit :
I didn't lie, I fixed the MSVC issues. Also I asked on how to compile with gcc4.4~c0x, but I got no answer and I do not know where to look.
I didn't see you asking. You can compile with gcc 4.4 in C++11 mode pretty much the same way as you can with newer gcc versions - by adding -std=c++0x or -std=gnu++0x to the command line.
gcc 4.4 is still failing.
http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
I believe this code is correct:
#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST static std::map<char,char const*> const char_type{{ {'<' , "lt"}, {'>' , "gt"}, {'&' , "amp"}, {'\'', "apos"}, {'"' , "quot"} }}; #else /.../
Maybe I am missing something.
You're using unified initialization syntax, which is indicated by BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX. BOOST_NO_CXX11_HDR_INITIALIZER_LIST indicates <initializer_list> header absence. If you use both, like in the code above, then you should be checking both macros.
...
What am I supposed to do with this log? http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_6...
or that: http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP...
?
Why aren't the runners be able to capture the outputs?
Yes, this is a common problem with the current infrastructure. As far as I understand the scripts are not always able to pinpoint the source of failure and as a result the link points to a random console output.
Testers do have a full log and upon request on this mailing list may be able to provide it.
as well as mingw testers hosted by Ion:
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
Maybe because of "-Werror=unused-parameter" ? or maybe this one is hiding something else?
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
and maybe because of "-Werror=sign-compare" ? or again this is hiding something else that was cut off in the report...
Nothing is hidden, the command line is shown in the output and it contains -Werror. My point is that these warnings should probably be fixed or silenced.
I was referring to a more serious problem that is hidden by this warning. But again, if I need to ask the logs at every commits, this is not really helping me saving time as a developer. BTW, is there any policy about warnings?
I believe this is the wrong thing to do for those runners: raising those trivial warnings as errors makes them quite useless and this is a waste of time and resource for everybody.
Is boost.test compiling for the end users of those platform? I do not know. Those runners are telling just nothing.
I've posted links to the concrete build errors, with command lines, isn't that enough? If you see your tests are failing and don't see any meaningful errors in the output, you could at least ask here instead of silently ignoring the failures.
Yes, and I thank you again for your active implication in the quality of boost.test and your relevant feedbacks. And I do not look at the regression dashboard every hours, hoping that some new runners have cycled. If the result is not there the next day basically, it is naturally/involuntary discarded.
Really, I'm very disappointed by Boost.Test quality lately.
What is the point you are trying to make?
I'm saying that I'm seeing lots of failures caused by Boost.Test in my tests that were passing before for a long time. First caused by inadvertent switch to C++11 only, then the breakage that started this thread. This doesn't help my development.
Now you pin pointed the error and the notion I was missing in this init list, I will be able to fix the error. Again, thank you, and sorry.
On my side, I believe the regression workflow and tools **can and should** be improved (runners cycling more frequently, outputs properly captured, history, no downtime due to some big zip file, better ergonomy, more responsive, etc etc).
I'm not happy with regression infrastructure myself, but that's irrelevant to the problems I'm pointing out in this thread.
I believe this is: if I were able to have a status on our develop branch without annoying anyone else, that would definitely help you. If the runners were cycling more often, if I had the history, I would be able to track down the regressions much more effectively. For being able to lower the noise/coupling with other libraries, I had to deploy a full CI solution with another branching scheme. This is supposed to be handled by the regression tools and obviously doing all that CI duplication takes a precious time, a time that is taken from the development/improvement of boost.test. So next I will just add gcc 4.4 C++0x to my CI to catch those error before they affect you. Raffi
On 11/21/2015 09:54 PM, Raffi Enficiaud wrote:
#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST static std::map<char,char const*> const char_type{{ {'<' , "lt"}, {'>' , "gt"}, {'&' , "amp"}, {'\'', "apos"}, {'"' , "quot"} }}; #else /.../
I would replace the std::map with a switch statement in this case. Then there is no need for an #ifndef.
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
and maybe because of "-Werror=sign-compare" ? or again this is hiding something else that was cut off in the report...
The problem is that if we test an unsigned integer against a literal integer value, then we a warning in the first test but not the second: unsigned int value = 1; BOOST_REQUIRE(value == 1); // No sign compare warning BOOST_REQUIRE_EQUAL(value, 1); // Sign compare warning The quick fix is for all Boost.Test users to do: BOOST_REQUIRE_EQUAL(value, 1U); but this is inconvenient if you do not know the signedness of the type, e.g. when you use a size() member function on some container.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Bjorn Reese Sent: 22 November 2015 16:21 To: boost@lists.boost.org Subject: Re: [boost] [teeks99][test] Test failures on MSVC 8-11
On 11/21/2015 09:54 PM, Raffi Enficiaud wrote:
#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST static std::map<char,char const*> const char_type{{ {'<' , "lt"}, {'>' , "gt"}, {'&' , "amp"}, {'\'', "apos"}, {'"' , "quot"} }}; #else /.../
I would replace the std::map with a switch statement in this case. Then there is no need for an #ifndef.
http://www.boost.org/development/tests/develop/developer/output/igazt anaga-gcc-5-1c++14-boost-bin-v2-libs-log-test-attr_function-test-gcc- mngw-5-1c+-dbg-dbg-symbl-off-thrd-mlt.html
and maybe because of "-Werror=sign-compare" ? or again this is hiding something else that was cut off in the report...
The problem is that if we test an unsigned integer against a literal integer value, then we a warning in the first test but not the second:
unsigned int value = 1; BOOST_REQUIRE(value == 1); // No sign compare warning BOOST_REQUIRE_EQUAL(value, 1); // Sign compare warning
The quick fix is for all Boost.Test users to do:
BOOST_REQUIRE_EQUAL(value, 1U);
but this is inconvenient if you do not know the signedness of the type, e.g. when you use a size() member function on some container.
I think that Boost.Test behaviour is correct/best here and that users should be providing the right type for the test, even if a bit more work and/or thought. For size() items one should best use size_t or size_type? And in general BOOST_REQUIRE_EQUAL rather than BOOST_REQUIRE is usually much more helpful in telling *why* the test has failed. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...
and maybe because of "-Werror=sign-compare" ? or again this is hiding something else that was cut off in the report...
I believe this is the wrong thing to do for those runners: raising those trivial warnings as errors makes them quite useless and this is a waste of time and resource for everybody.
I think I should not use Werror on regressions, this was a copy paste error from the user-config.jam I use to test my libraries, where I try to be warning free. It should be fixed for the next run. Best, Ion
participants (6)
-
Andrey Semashev -
Bjorn Reese -
Ion Gaztañaga -
Paul A. Bristow -
Raffi Enficiaud -
Tom Kent