blob: b17fa361811b42fb4c517f2b405279e33c8416e1 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
<?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>
|
