Blame view

3rdparty/boost_1_81_0/libs/contract/meta/explicit-failures-markup.xml 10.4 KB
977ed18d   Hu Chunming   提交三方库
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
  <?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>