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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
