[PATCH] D14653: [libcxx] Introduce the mechanism for fixing -fno-exceptions test failures.
Asiri Rathnayake via cfe-commits
cfe-commits at lists.llvm.org
Thu Jan 28 02:19:15 PST 2016
rmaprath added inline comments.
Comment at: test/support/noexcept.h:23
@@ +22,3 @@
+// tests use multiple catch statements, in those cases we have to use the
+// _LIBCPP_NO_EXCEPTIONS macro and exclude the additional catch statements.
> I don't care for this; I think that "implementing a mechanism for throwing exceptions in the test suite for when we've disabled exceptions" seems like something that we'll have to revisit time and time again.
> I wonder if it would be better to just split some tests into multiple tests (some parts that test exception handling, some that don't), and then XFAIL: no-exceptions the ones that test exception handling.
Not sure if I follow. This mechanism is not about throwing exceptions in the test suite; it is to check that the **library** calls __libcxx_noexceptions_abort() where it previously (with-exceptions) used to throw.
I don't see how splitting the tests would allow us to check that the library calls __libcxx_noexceptions_abort() as appropriate. We can XFAIL the tests that does exception handling, but then we won't be checking the library's behaviour in exceptional situations (i.e. how does it react to exceptional situations in the absence of exceptions?).
If we define that the no-exceptions library's behaviour in exceptional situations is *undefined*, then your suggestion makes sense, as then we don't have to worry about calling __libcxx_noexceptions_abort(). But this is not what we agreed upon in the dev list.
More information about the cfe-commits