[PATCH] D137381: [clang][compiler-rt] Exception escape out of an non-unwinding function is an undefined behaviour

[John McCall via Phabricator via llvm-commits]

rjmccall added a comment.

> The more i stare at this. The more worried i am. Is the idea that, when we are in termination/UB EH scope, we no longer have to play by the RAII rules, and destructors, for the moment, are no-ops and are side-effect free?

Termination is allowed to happen as soon as the implementation detects that unwinding will only avoid termination if a cleanup does something non-terminating, like infinite loop or abort.  This does enable some amount of code-size optimization, but the main purpose (as I understand it) is to improve debugging of what's presumed to be a programmer error by allowing the runtime to trigger termination with the faulting context still intact instead of requiring the stack to be unwound just to, like, deallocate a temporary `std::string` ten frames up.

The important thing for us is that the standard explicitly blesses this presumption: it has been decided that C++ programmers should not be relying on destructors being called when their programs throw in a context where the implementation has no choice but to terminate, and if they really need unwinding to happen, they should be handling exceptions properly.  I don't think that's an unreasonable rule.  (Note that it is limited to failures to formally handle exceptions, not some sort of post-domination by `std::terminate`.  If you catch an exception and then call `std::terminate` yourself, the rule does not apply, and the stack is required to be unwound to the `catch`.)  Also, it's a rule that Clang already takes advantage of within terminate scopes, which are otherwise well-defined, so I do think it would be fairly absurd to act like these UB scopes need stricter rules about running cleanups.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137381/new/

https://reviews.llvm.org/D137381