From a2031c17a79ec118f93d84a3e3e960050ec3ee38 Mon Sep 17 00:00:00 2001 From: Automated Commit Date: Sat, 13 Jan 2018 10:45:47 +0000 Subject: Update explicit-failures-markup.xml [skip ci] --- status/explicit-failures-markup.xml | 281 ++++++++++++++++++++++++++++++++++-- 1 file changed, 265 insertions(+), 16 deletions(-) (limited to 'status') diff --git a/status/explicit-failures-markup.xml b/status/explicit-failures-markup.xml index 1674245355..4998d6ce7b 100644 --- a/status/explicit-failures-markup.xml +++ b/status/explicit-failures-markup.xml @@ -867,24 +867,273 @@ + + + + Tests fail to link on this compiler when libc++ is used (see + https://tracker.crystax.net/issues/1403). + This linker error does not occur with libstdc++ but + unfortunately the toolset name for this compiler does not + differentiate between libc++ and libstdc++ runs so also + libstdc++ tests had to be marked as expected failures (even if + they actually pass). + + + + + + + + Even tests that do not use C++11 lambda functions fail on this + compiler because it incorrectly attempts an extra copy when + objects are constructed via `boost::check c = ...`. + This is fixed in MinGW GCC 4.3. + + + + + + Even tests that do not use C++11 lambda functions fail on this + compiler because of a number of different issues + (Boost.Exception, which used by this library, also is not + supported on this compiler, incorrect implementation of some + aspects of friendship, incorrect dispatching of some `volatile` + calls, etc.). + These specific issues are fixed in MSVC 9.0 (but only MSVC 11.0 + has adequate lambda function support that makes this library + actually usable). + + - - - - - - - - - - - - - - + + + + + This test fails on this compiler because of a bug in libc++ + (see http://grokbase.com/t/gg/android-ndk/1656csqqtp/assertion-ttypeencoding-dw-eh-pe-absptr-unexpected-ttypeencoding-failed). + This is fixed in libstdc++. + + + + + + + + + + + This test fails on this compiler because of a bug in libstdc++ + (undefined references to `std::ios_base::failure::failure`). + This is fixed in libc++. + + + + + + + + + + + + + + + + This test fails because of a libcxxrt bug on Clang for FreeBSD + which causes `std::uncaught_exception` to not work properly on + re-throws (see https://github.com/pathscale/libcxxrt/issues/49). + + + + + + + + + + + + + + This test fails because C++17 guarantees no copies on function + returns by value (so this library can only give run-time errors, + and not compile-time errors, if auto declarations are misused + instead of using the `boost::contract::check` type explicitly on + C++17 compilers). + + + + + + + + + + + + + + It is not clear why this test fails but when trying to install + MinGW GCC 6.1 using `mingw-get` it says that such a compiler + version does not exist (so this issue could not be investigated + any further). + This is fixed in MinGW GCC 6.2. + + + + + + + + + + + + + + + This test fails because this complier does not properly + implement SFINAE giving incorrect errors on substitution + failures for private members. + This seems to be fixed in GCC 4.8 and MSVC 12.0. + + + + + + + + + + + This test fails because SFINAE on this complier seems to not + fail as it should when a derived class tries to call a + protected member function on a base class object via a function + pointer instead of via inheritance. + This seems to be fixed in Clang 3.1, and to be specific to + version 4.6 of GCC. + + + + + + + + + + + + This test fails because this compiler seems to incorrectly check + access level of members in base classes in a context when only + derived class members are used. + This seems to be fixed in GCC 4.8 (possibly related to + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973). + + + + + + + GCC 8 has not been released yet so this test might be failing + because of some work-in-progress aspect of the compiler. + This test did not fail on GCC 7. + + + + + + + + + + + + + + + + + + + + + + + + + This test fails because `std::unchaught_exception` seems to + always return zero on this compiler (even if the authors could + not find a direct reference to this possible compiler issue + online). + + + + + + + This test fails because MSVC 10.0 is not able to properly deduce + a template specialization. + This is fixed in MSVC 11.0. + + + + + + + + This test fails because of a MSVC 10.0 bug with lambdas within + template class initialization list. + This can be worked around using a functor bind instead of a + lambda, but it is fixed in MSVC 11.0. + + + + + + + This test fails because of a MSVC 10.0 bug for which lambdas + cannot access typedefs declared within classes. + This can be worked around declaring typedefs outside of + classes, but it is fixed in MSVC 11.0. + + + + + + + + + + + + This test fails because of an internal MSVC 10.0 compiler bug. + This is fixed in MSVC 11.0. + + + + + + + + + This test fails because this complier seems to dispatch calls + incorrectly when both `const` and `const volatile` overloads + are present (even if the authors could not find a direct + reference to this possible compiler issue online). + This is fixed in MSVC 9.0 (but only MSVC 11.0 has adequate + lambda function support). + + + + + + + - Most tests require lambda function support (even if technically - the library itself does not require lambdas). + This test fails because of this compiler/platform cause an + error in Boost.TypeTraits (this could be fixed in the master + branch... not sure). -- cgit v1.2.1