This is an archive of the discontinued LLVM Phabricator instance.

Protect nested-exceptions tests under no-exceptions
ClosedPublic

Authored by rogfer01 on Nov 9 2016, 9:26 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

rogfer01 updated this revision to Diff 77363.Nov 9 2016, 9:26 AM
rogfer01 retitled this revision from to Protect nested-exceptions tests under no-exceptions.
rogfer01 updated this object.
rogfer01 added reviewers: mclow.lists, EricWF, rmaprath.
rogfer01 added a subscriber: cfe-commits.
rmaprath edited edge metadata.Nov 9 2016, 11:50 AM

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?

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.

EricWF accepted this revision.Nov 14 2016, 1:40 AM
EricWF edited edge metadata.

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?

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.

This revision is now accepted and ready to land.Nov 14 2016, 1:40 AM
This revision was automatically updated to reflect the committed changes.

There are cases where it is useful to be able to name std::nested_exception while exceptions are disabled.

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.