Gennadiy, Could you please take a look at/comment on the current Boost.Test failures as per http://tinyurl.com/5wojs? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m2pt4dkz59.fsf@meta-comm.com...
Gennadiy,
Could you please take a look at/comment on the current Boost.Test failures as per http://tinyurl.com/5wojs?
Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering
Could you please point me to docs that describe how to mark test as expected failure. Gennadiy.
Gennadiy Rozental writes:
Could you please point me to docs that describe how to mark test as expected failure.
To mark a number of test case failures on a number of particular toolsets as "expected", you add an entry to "status/explicit-failures-markup.xml" along the following lines: <!-- test --> <library name="test"> <mark-expected-failures> <test name="test_case1"/> <test name="test_case2"/> ... <toolset name="toolset1"/> <toolset name="toolset2"/> ... <note author="Gennadiy Rozental"> This failure is due to Reason #1. </note> </mark-expected-failures> <mark-expected-failures> <test name="test_case7"/> <test name="test_case9"/> ... <toolset name="toolset1"/> <toolset name="toolset5"/> ... <note author="Gennadiy Rozental"> This failure is due to Reason #2. </note> </mark-expected-failures> ... </library> Then you validate the modified XML following the instructions at the very top of the file: The following online services can be used to validate your changes to this file: - http://apps.gotdotnet.com/xmltools/xsdvalidator/ When using the gotdotnet tool you need to provide both the explicit-failures-markup.xml file as the XML document and the explicit-failures.xsd as the schema document. Use the browse buttons to select them from your local hard drive. ... and if everything is OK, check it in. That's it. HTH, -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy writes:
Gennadiy Rozental writes:
Could you please point me to docs that describe how to mark test as expected failure.
To mark a number of test case failures on a number of particular toolsets as "expected", you add an entry to "status/explicit-failures-markup.xml" along the following lines:
[snip the explanation] Gennadiy, Do you still have problems with the markup procedure? At the moment Boost.Test is the worst-looking library in the reports summary, and I'm starting to fear that it might end up being a bottleneck for the release. It would be very much appreciated if you could clear up the field within the next two days. Thanks in advance, -- Aleksey Gurtovoy MetaCommunications Engineering
Any help with this one? ### mwcc Compiler: # In: ..\boost\mpl\next_prior.hpp # From: ..\libs\test\test\basic_cstring_test.cpp # ------------------------------------------------- # 31: typedef typename T::next type; # Error: ^ # 'next' is not a member of class 'boost::mpl::l_iter<boost::mpl::l_end>' # (instantiating: 'boost::unit_test::test_case_template<meta_constructors_test, boost::mpl::joint_view<boost::mpl::l_item<boost::mpl::long_<3>, const char, boost::mpl::l_item<boost::mpl::long_<2>, const unsigned char, boost::mpl::l_item<boost::mpl::long_<1>, const wchar_t, boost::mpl::l_end>>>, boost::mpl::list<char, unsigned char, wchar_t, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na>>>::do_run()') # (instantiating: 'boost::mpl::for_each<boost::mpl::joint_view<boost::mpl::l_item<boost::mpl:: long_<3>, const char, boost::mpl::l_item<boost::mpl::long_<2>, const unsigned char, boost::mpl::l_item<boost::mpl::long_<1>, const wchar_t, boost::mpl::l_end>>>, boost::mpl::list<char, unsigned char, wchar_t, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na>>, boost::mpl::make_identity<boost::mpl::arg<-1>>, boost::unit_test::ut_detail::test_case_instance_runner<meta_constructors_tes t>>(boost::unit_test::ut_detail::test_case_instance_runner<meta_constructors _test>, boost::mpl::joint_view<boost::mpl::l_item<boost::mpl::long_<3>, const char, boost::mpl::l_item<boost::mpl::long_<2>, const unsigned char, boost::mpl::l_item<boost::mpl::long_<1>, const wchar_t, boost::mpl::l_end>>>, boost::mpl::list<char, unsigned char, wchar_t, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na>> *, boost::mpl::make_identity<boost::mpl::arg<-1>> *)') # (instantiating: 'boost::mpl::aux::joint_iter<boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_end>>') # (instantiating: 'boost::mpl::next<boost::mpl::l_iter<boost::mpl::l_end>>') ### mwcc Compiler: # In: ..\boost\mpl\deref.hpp # ------------------------------- # 30: typedef typename Iterator::type type; # Error: ^ # 'type' is not a member of class 'boost::mpl::l_iter<boost::mpl::l_end>' # (instantiating: 'boost::unit_test::test_case_template<meta_constructors_test, boost::mpl::joint_view<boost::mpl::l_item<boost::mpl::long_<3>, const char, boost::mpl::l_item<boost::mpl::long_<2>, const unsigned char, boost::mpl::l_item<boost::mpl::long_<1>, const wchar_t, boost::mpl::l_end>>>, boost::mpl::list<char, unsigned char, wchar_t, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na>>>::do_run()') # (instantiating: 'boost::mpl::for_each<boost::mpl::joint_view<boost::mpl::l_item<boost::mpl:: long_<3>, const char, boost::mpl::l_item<boost::mpl::long_<2>, const unsigned char, boost::mpl::l_item<boost::mpl::long_<1>, const wchar_t, boost::mpl::l_end>>>, boost::mpl::list<char, unsigned char, wchar_t, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na>>, boost::mpl::make_identity<boost::mpl::arg<-1>>, boost::unit_test::ut_detail::test_case_instance_runner<meta_constructors_tes t>>(boost::unit_test::ut_detail::test_case_instance_runner<meta_constructors _test>, boost::mpl::joint_view<boost::mpl::l_item<boost::mpl::long_<3>, const char, boost::mpl::l_item<boost::mpl::long_<2>, const unsigned char, boost::mpl::l_item<boost::mpl::long_<1>, const wchar_t, boost::mpl::l_end>>>, boost::mpl::list<char, unsigned char, wchar_t, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na>> *, boost::mpl::make_identity<boost::mpl::arg<-1>> *)') # (instantiating: 'boost::mpl::aux::joint_iter<boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_end>>') # (instantiating: 'boost::mpl::deref<boost::mpl::l_iter<boost::mpl::l_end>>') Gennadiy.
Gennadiy Rozental writes:
Any help with this one?
### mwcc Compiler: # In: ..\boost\mpl\next_prior.hpp # From: ..\libs\test\test\basic_cstring_test.cpp # ------------------------------------------------- # 31: typedef typename T::next type; # Error: ^ # 'next' is not a member of class 'boost::mpl::l_iter<boost::mpl::l_end>' # (instantiating: [...]
I know what's going on here; I'll take care of it later today. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy writes:
Gennadiy Rozental writes:
Any help with this one?
### mwcc Compiler: # In: ..\boost\mpl\next_prior.hpp # From: ..\libs\test\test\basic_cstring_test.cpp # ------------------------------------------------- # 31: typedef typename T::next type; # Error: ^ # 'next' is not a member of class 'boost::mpl::l_iter<boost::mpl::l_end>' # (instantiating: [...]
I know what's going on here; I'll take care of it later today.
Fixed in the CVS now. -- Aleksey Gurtovoy MetaCommunications Engineering
Does anybody with compiler access could give me a hint on source/resolution for this error: "..\libs\test\test\basic_cstring_test.cpp", line 110: error #304: no instance of function template "test_string" matches the argument list argument types are: ( boost::mpl::aux::resolve_bind_arg<boost::mpl::bind1<boost ::mpl::quote1<boost::mpl::make_identity, mpl_::void_>, boost::mpl::lambda<mpl_::_, mpl_::void_>::result_>::apply<boost::mpl::deref<boost::mp l::begin<boost::mpl::joint_view<const_char_types, mutable_char_types>>::type>::type, mpl_::na, mpl_::na, mpl_::na, mpl_::na>::a1, boost::mpl::deref<boost::mpl::begin<boost::mpl::joint_vie w<const_char_types, mutable_char_types>>::type>::type, mpl_::na, mpl_::na, mpl_::na, mpl_::na>::type *) utf::basic_cstring<CharT> bcs( TEST_STRING ); Full error message could be found here: http://tinyurl.com/3rhrz Thanx, Gennadiy.
Subject test pass on my local installation. Could somebody, who actually runs regression tests, check what is going on? Gennadiy.
Gennadiy Rozental ha escrito:
Subject test pass on my local installation. Could somebody, who actually runs regression tests, check what is going on?
Seems like the problem is not inside basic_cstring itself, but in unit_test_suite.cpp. In particular, the *second* time the program gets to the following memfun, it gets stuck: inline bool test_case::Impl::check_dependencies() { return std::find_if( m_dependencies_list.begin(), m_dependencies_list.end(), std::not1( boost::mem_fn( &test_case::has_passed ) ) ) == m_dependencies_list.end(); } The apparent cause for the hang up is that m_dependencies_list is somehow corrupt. Note this does not happen the first time test_case::Impl::check_dependencies is called, but the second. I'd say the underlying problem is the same that's causing a regression at http://tinyurl.com/4mmsg The code is beyond my analysis skills, but I can provide you with remote support if you want to get more info or try some workaround. Just drop me an email. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Subject test fails at runtime with following output: Running 58 test cases... ../libs/test/test/basic_cstring_test.cpp(419): error in "io_test": ostr.is_equal( "test" ) failed. Output content: "tes" ../libs/test/test/basic_cstring_test.cpp(419): error in "io_test": ostr.is_equal( "test" ) failed. Output content: "tes" *** 2 failures detected in test suite "basic_cstring test" Interesting lines are: bcs1 = "test"; ... ostr << std::setw( 3 ) << bcs1; BOOST_CHECK( ostr.is_equal( "test" ) ); Looks like setw manipulator set maximum field width, while it supposed to set minimum. Is this compiler/STL bug? Gennadiy.
Subject test fails in Iterator library: "F:\boost\boost/iterator/iterator_facade.hpp", line 534: error #265-D: function "boost::unit_test::input_iterator_facade<Derived, ValueType, Reference, Traversal>::equal [with Derived=boost::unit_test::basic_string_token_iterator<char, boost::unit_test::ut_detail::default_char_compare<char>>, ValueType=boost::unit_test::basic_cstring<const char>, Reference=boost::unit_test::basic_cstring<const char>, Traversal=boost::forward_traversal_tag]" is inaccessible return f1.equal(f2); class input_iterator_adaptor define like this: class input_iterator_facade : public iterator_facade<...> { ... private: friend class iterator_core_access; ... // iterator facade interface implementation bool equal( input_iterator_facade const& rhs ) const { ... } }; Any recommendations? Gennadiy.
The same applies to tru64cxx65 toolset. Gennadiy.
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
class input_iterator_adaptor define like this:
class input_iterator_facade : public iterator_facade<...> { ... private: friend class iterator_core_access;
...
// iterator facade interface implementation bool equal( input_iterator_facade const& rhs ) const { ... } };
Any recommendations?
Is input_iterator_facade defined in the same namespace as iterator_core_access? If not, the friend declaration is doing the wrong thing. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
class input_iterator_adaptor define like this:
class input_iterator_facade : public iterator_facade<...> { ... private: friend class iterator_core_access;
...
// iterator facade interface implementation bool equal( input_iterator_facade const& rhs ) const { ... } };
Any recommendations?
Is input_iterator_facade defined in the same namespace as iterator_core_access? If not, the friend declaration is doing the wrong thing.
-- Dave Abrahams
input_iterator_facade reside in namespace boost::unit_test. Note that this test works for many compilers and fails (in this place) only for subject configuration. Gennadiy.
Gennadiy Rozental wrote:
class input_iterator_adaptor define like this:
class input_iterator_facade : public iterator_facade<...> Any recommendations?
Is input_iterator_facade defined in the same namespace as iterator_core_access? If not, the friend declaration is doing the wrong thing.
-- Dave Abrahams
input_iterator_facade reside in namespace boost::unit_test.
If you intend to make boost::iterator_core_access friend the friend declaration is indeed wrong as Dave suggested. There is basically no name lookup for friend declarations. I.e. a non qualified name in a friend declaration either declares a class/function in the current namespace or "refers" to such a thing that is in the current namespace. of boost you need to say friend class boost::iterator_core_accessIn order to make boost::iterator_core_access friend from a sub namespace. HTH Thomas -- Thomas Witt witt@acm.org
If you intend to make boost::iterator_core_access friend the friend declaration is indeed wrong as Dave suggested. There is basically no name lookup for friend declarations. I.e. a non qualified name in a friend declaration either declares a class/function in the current namespace or "refers" to such a thing that is in the current namespace.
of boost you need to say friend class boost::iterator_core_accessIn order to make boost::iterator_core_access friend from a sub namespace.
HTH
Thomas
You basically saying that following is incorrect: namespace out { class A {}; namespace in { class B { friend class A; }; } // namespace in } // namespace out I bit strange. After all at the point of friend statement there is symbol A that fit the bill. Why exactly standard doing that? Gennadiy.
Gennadiy Rozental wrote:
You basically saying that following is incorrect:
namespace out {
class A {};
namespace in {
class B { friend class A; };
} // namespace in
} // namespace out
Well it's incorrect if the goal is to make out::A a friend of out::in::B.
I bit strange.
Well, yes.
After all at the point of friend statement there is symbol A that fit the bill. Why exactly standard doing that?
Sorry but I don't have the rationale. Thomas -- Thomas Witt witt@acm.org
participants (5)
-
Aleksey Gurtovoy -
David Abrahams -
Gennadiy Rozental -
Joaquín Mª López Muñoz -
Thomas Witt