Skip tests that expect an exception be thrown.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Not sure if either of these tests add much value to the no-exceptions variant, using std::nested_exception with such a library seem pointless to me. Perhaps marking these as UNSUPPORTED is a better fix?
Also, it seems like we are saving the same assert in all the three tests. If we want to save it that badly, perhaps creating a new test case with a REQUIRES: libcpp-no-exceptions is a better fix.
@rmaprath well each case is testing a different special member: the assignment operator, the copy constructor and the default constructor. My feeling is that at least the non-throwing part must be tested under no-exceptions. But I understand, that this class is probably useless in the context of no-exceptions.
There are cases where it is useful to be able to name std::nested_exception while exceptions are disabled. I agree with @rogfer01 on this patch.
I was thinking about the opposite. That is, we might want to consider disabling the <exception> header altogether when compiling with -fno-exceptions. My particular use case is to do with futures:
void make_hello(std::promise<std::string> &p, bool set_exception) { if (set_exception) p.set_exception(std::make_exception_ptr( std::runtime_error {"No hellos left."})); else p.set_value("Hello world!"); }
This will compile fine with -fno-exceptions and when the client thread attempts to read from the promise, whole program would crash. May be they deserve it, but I feel like it's something we can help with; if we disable the <exception> header, this code wouldn't compile under -fno-exceptions.
In what cases do we need to allow various exception types under -fno-exceptions?
Cheers,
/ Asiri
On the other hand, disabling <exception> would mean disabling some parts of the library as well (in this case, std::promise::set_exception). Perhaps that's a bad path to follow. Not sure.