-
Richard Smith authored
We continue to support dynamic exception specifications in C++1z as an extension, but produce an error-by-default warning when we encounter one. This allows users to opt back into the feature with a warning flag, and implicitly opts system headers back into the feature should they happen to use it. There is one semantic change implied by P0003R5 but not implemented here: violating a throw() exception specification should now call std::terminate directly instead of calling std::unexpected(), but since P0003R5 also removes std::unexpected() and std::set_unexpected, and the default unexpected handler calls std::terminate(), a conforming C++1z program cannot tell that we are still calling it. The upside of this strategy is perfect backwards compatibility; the downside is that we don't get the more efficient 'noexcept' codegen for 'throw()'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289019 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith authoredWe continue to support dynamic exception specifications in C++1z as an extension, but produce an error-by-default warning when we encounter one. This allows users to opt back into the feature with a warning flag, and implicitly opts system headers back into the feature should they happen to use it. There is one semantic change implied by P0003R5 but not implemented here: violating a throw() exception specification should now call std::terminate directly instead of calling std::unexpected(), but since P0003R5 also removes std::unexpected() and std::set_unexpected, and the default unexpected handler calls std::terminate(), a conforming C++1z program cannot tell that we are still calling it. The upside of this strategy is perfect backwards compatibility; the downside is that we don't get the more efficient 'noexcept' codegen for 'throw()'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289019 91177308-0d34-0410-b5e6-96231b3b80d8
Code owners
Assign users and groups as approvers for specific file changes. Learn more.