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.
+#ifndef _LIBCPP_NO_EXCEPTIONS
----------------
mclow.lists wrote:
> 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.

WDYT?


http://reviews.llvm.org/D14653



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to