<?xml version="1.0" encoding="utf-8"?>

<!--
Copyright (C) 2008-2018 Lorenzo Caminiti
Distributed under the Boost Software License, Version 1.0 (see accompanying
file LICENSE_1_0.txt or a copy at http://www.boost.org/LICENSE_1_0.txt).
See: http://www.boost.org/doc/libs/release/libs/contract/doc/html/index.html
-->

<!--
PLEASE VALIDATE THE XML BEFORE COMMITTING YOUR CHANGES!

For example, cut-n-paste <library> tag below into main file
"boost/status/explicit-failures-markup.xml" and validate as indicated in that
main file.
-->

<explicit-failures-markup>
    <!-- contract -->
    <library name="contract">
        <mark-unusable>
            <toolset name="clang-darwin-ubsan"/>
            <note author="Lorenzo Caminiti">
                On this compiler, Boost.Function gives a run-time error when
                calling non-nullary lambdas as used by the tests of this library
                to program contract failure handlers.
                It might still be possible to use this library on this compiler
                using default contract failure handlers or programming custom
                contract failure handlers but without using non-nullary lambdas
                (however, the authors did not confirm that).
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="gcc-3.*"/>
            <toolset name="gcc-4.*"/>
            <note author="Lorenzo Caminiti">
                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 using `boost::check c = ...`.
                This is fixed in MinGW GCC 4.3.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="msvc-7.*"/>
            <note author="Lorenzo Caminiti">
                Even tests that do not use C++11 lambda functions fail on this
                compiler because of a number of issues (Boost.Exception is not
                supported on this compiler but it is used by this library
                implementation, some aspects of `friend` and `volatile` are not
                properly implemented on this compiler, 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).
            </note>
        </mark-unusable>
        <mark-expected-failures>
            <test name="disable-audit"/>
            <toolset name="gcc-4.9"/>
            <toolset name="clang-linux-3.6"/>
            <toolset name="clang-linux-3.7"/>
            <toolset name="clang-linux-3.8"/>
            <note author="Lorenzo Caminiti">
                This test fails on this compiler because of a bug with
                exceptions (see http://grokbase.com/t/gg/android-ndk/1656csqqtp/assertion-ttypeencoding-dw-eh-pe-absptr-unexpected-ttypeencoding-failed).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="invariant-ifdef"/>
            <test name="specify-nothing"/>
            <toolset name="clang-linux-3.6"/>
            <toolset name="clang-linux-3.7"/>
            <toolset name="clang-linux-3.8"/>
            <note author="Lorenzo Caminiti">
                This test fails on this compiler because of a bug in its STL
                implementation (undefined references to
                `std::ios_base::failure::failure`).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="destructor-throwing_old"/>
            <test name="destructor-throwing_post"/>
            <test name="public_function-decl_pre_all"/>
            <test name="public_function-decl_pre_ends"/>
            <test name="public_function-smoke"/>
            <test name="public_function-throwing_post"/>
            <test name="public_function-virtual"/>
            <test name="public_function-virtual_branch"/>
            <toolset name="clang-linux-*~gnu++*"/>
            <note author="Lorenzo Caminiti">
                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).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="old-if_copyable"/>
            <test name="old-if_copyable_macro"/>
            <toolset name="gcc-4.6*"/>
            <toolset name="gcc-4.7*"/>
            <toolset name="msvc-10.*"/>
            <toolset name="msvc-11.*"/>
            <note author="Lorenzo Caminiti">
                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.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="public_function-protected_error"/>
            <toolset name="clang-linux-3.0~*"/>
            <toolset name="gcc-4.6*"/>
            <note author="Lorenzo Caminiti">
                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.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="public_function-virtual_access_multi"/>
            <toolset name="gcc-4.6*"/>
            <toolset name="gcc-4.7*"/>
            <note author="Lorenzo Caminiti">
                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).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="constructor-throwing_body"/>
            <test name="destructor-decl_entry_inv_all"/>
            <test name="destructor-decl_entry_inv_ends"/>
            <test name="destructor-decl_entry_static_inv_all"/>
            <test name="destructor-decl_entry_static_inv_ends"/>
            <test name="destructor-decl_entry_static_inv_mid"/>
            <test name="destructor-decl_exit_static_inv_all"/>
            <test name="destructor-decl_exit_static_inv_ends"/>
            <test name="destructor-decl_exit_static_inv_mid"/>
            <test name="destructor-throwing_body"/>
            <test name="destructor-throwing_old"/>
            <test name="destructor-throwing_post"/>
            <test name="function-ifdef_macro"/>
            <test name="function-throwing_body"/>
            <test name="public_function-static_throwing_body"/>
            <test name="public_function-throwing_body"/>
            <test name="public_function-throwing_body_virtual"/>
            <test name="public_function-throwing_body_virtual_branch"/>
            <toolset name="qcc-4.7*"/>
            <note author="Lorenzo Caminiti">
                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).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="invariant-ifdef"/>
            <test name="invariant-ifdef_macro"/>
            <test name="invariant-volatile_error"/>
            <toolset name="msvc-8.*"/>
            <note author="Lorenzo Caminiti">
                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).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="call_if-no_equal_call_if"/>
            <toolset name="msvc-10.*"/>
            <note author="Lorenzo Caminiti">
                This test fails because MSVC 10.0 is not able to properly deduce
                a template specialization.
                This is fixed in MSVC 11.0.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="constructor-ifdef_macro"/>
            <test name="constructor-smoke"/>
            <toolset name="msvc-10.*"/>
            <note author="Lorenzo Caminiti">
                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.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="destructor-smoke"/>
            <toolset name="msvc-10.*"/>
            <note author="Lorenzo Caminiti">
                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.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="disable-no_post_except_lib"/>
            <test name="disable-no_post_except_unit"/>
            <test name="disable-nothing_for_pre_prog"/>
            <test name="disable-other_assertions_lib"/>
            <test name="disable-other_assertions_prog"/>
            <test name="disable-other_assertions_unit"/>
            <toolset name="msvc-10.*"/>
            <note author="Lorenzo Caminiti">
                This test fails because of an internal MSVC 10.0 compiler bug.
                This is fixed in MSVC 11.0.
            </note>
        </mark-expected-failures>
    </library>
</explicit-failures-markup>

