[libcxx-commits] [PATCH] D154238: [libc++][PSTL] Move exception handling to the CPU backends

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added inline comments.


================
Comment at: libcxx/include/__algorithm/pstl_backend.h:159-160
+The backend is expected to terminate on any user-thrown exceptions. This includes exceptions which are thrown by a
+parallel algorithm which is invoked inside another algorithm. If any allocation fails, the backend shall throw
+std::bad_alloc.
 */
----------------
And also below.


================
Comment at: libcxx/include/__algorithm/pstl_backends/cpu_backend.h:51
+
+The backend is expected to terminate on any user-thrown exceptions. This includes exceptions which are thrown by a
+parallel algorithm which is invoked inside another algorithm. If any allocation fails, the backend shall throw
----------------



================
Comment at: libcxx/test/std/algorithms/alg.modifying.operations/alg.fill/pstl.fill.pass.cpp:27
 
+#include "check_assertion.h"
+
----------------
This include is not necessary.


================
Comment at: libcxx/test/std/algorithms/alg.modifying.operations/alg.fill/pstl.fill.terminate.pass.cpp:30
+  test_execution_policies([&](auto&& policy) {
+    EXPECT_STD_TERMINATE([&] { (void)std::fill(policy, std::begin(a), std::end(a), ThrowOnCopy{}); });
+    EXPECT_STD_TERMINATE([&] { (void)std::fill_n(policy, std::begin(a), std::size(a), ThrowOnCopy{}); });
----------------
Can we also test iterators that throw when some operation (e.g. increment) is applied to them? I think this might catch issues in backends when they e.g. compute the size of the range. For this algorithms but others as well.

Or throwing on copy of the iterator.

Actually, this raises the question of how to handle throwing iterators at all. I think this approach doesn't work, since an iterator could technically throw even in one of the frontend functions. It's possible that the only approach that will work is to actually make the top-level function `noexcept` (but still throw `std::bad_alloc` in a few cases).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154238