wrap comments at 80 columns

examples/algorithms/retry.hpp

@@ -26,7 +26,7 @@ using _copy_cvref_t = stdexec::__copy_cvref_t<From, To>;
 template <class From, class To>
 concept _decays_to = std::same_as<std::decay_t<From>, To>;
 
-///////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////
 // retry algorithm:
 
 // _conv needed so we can emplace construct non-movable types into
@@ -50,7 +50,8 @@ struct _conv
 template <class S, class R>
 struct _op;
 
-// pass through all customizations except set_error, which retries the operation.
+// pass through all customizations except set_error, which retries the
+// operation.
 template <class S, class R>
 struct _retry_receiver : exec::receiver_adaptor<_retry_receiver<S, R>>
 {

examples/algorithms/then.hpp

@@ -20,7 +20,7 @@
 #include <exec/receiver_adaptor.hpp>
 #include <stdexec/execution.hpp>
 
-///////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////
 // then algorithm:
 template <class R, class F>
 class _then_receiver : public exec::receiver_adaptor<_then_receiver<R, F>, R>
@@ -36,7 +36,8 @@ class _then_receiver : public exec::receiver_adaptor<_then_receiver<R, F>, R>
     , f_(std::move(f))
   {}
 
-  // Customize set_value by invoking the callable and passing the result to the inner receiver
+  // Customize set_value by invoking the callable and passing the result to the
+  // inner receiver
   template <class... As>
     requires stdexec::receiver_of<R, _completions<As...>>
   void set_value(As&&... as) && noexcept

examples/retry.cpp

@@ -20,7 +20,7 @@
 
 #include <cstdio>
 
-///////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////
 // Example code:
 struct fail_some
 {

examples/scope.cpp

@@ -22,7 +22,7 @@
 
 #include <cstdio>
 
-///////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////
 // Example code:
 using namespace stdexec;
 using stdexec::sync_wait;

examples/server_theme/let_value.cpp

@@ -150,7 +150,8 @@ auto main() -> int
       schedule_request_start(sched, i)
       // make sure the request is valid; throw if not
       | ex::let_value(validate_request)
-      // process the request in a function that may be using a different execution context
+      // process the request in a function that may be using a different
+      // execution context
       | ex::let_value(handle_request)
       // If there are errors transform them into proper responses
       | ex::let_error(error_to_response)

examples/server_theme/split_bulk.cpp

@@ -146,8 +146,8 @@ auto handle_edge_detection_request(http_request const & req) -> ex::sender auto
   // ex::sender auto multi_shot_img = exec::split(in_img_sender);
   auto& multi_shot_img = in_img_sender;
 
-  // Apply the three methods of edge detection on the same input image, in parallel.
-  // Then, join the results and generate the HTTP response
+  // Apply the three methods of edge detection on the same input image, in
+  // parallel. Then, join the results and generate the HTTP response
   return ex::when_all(multi_shot_img | ex::then(apply_canny),
                       multi_shot_img | ex::then(apply_sobel),
                       multi_shot_img | ex::then(apply_prewitt))

examples/sudoku.cpp

@@ -14,11 +14,11 @@
     Copyright 2026 NVIDIA Corp.
 */
 
-// This sudoku code was originally taken from TBB examples/thread_group/sudoku. The TBB
-// example leaks: https://github.com/oneapi-src/oneTBB/issues/568. The code was modified
-// by Kirk Shoop to use libunifex instead of TBB and to remove the leaks. The code was
-// later modified by David Olsen to use stdexec instead of libunifex to be a test in the
-// NVHPC test suite for stdexec.
+// This sudoku code was originally taken from TBB examples/thread_group/sudoku.
+// The TBB example leaks: https://github.com/oneapi-src/oneTBB/issues/568. The
+// code was modified by Kirk Shoop to use libunifex instead of TBB and to remove
+// the leaks. The code was later modified by David Olsen to use stdexec instead
+// of libunifex to be a test in the NVHPC test suite for stdexec.
 
 #include <cstdio>
 #include <cstdlib>
@@ -225,8 +225,8 @@ bool examine_potentials(board_element *b, bool *progress)
     // Check if potential_set is a power of 2 (only one bit set)
     if (std::popcount(b[i].potential_set) == 1)
     {
-      // It's a singleton - solve it
-      // countr_zero gives the bit position (0-indexed), add 1 to get the element value
+      // It's a singleton - solve it countr_zero gives the bit position
+      // (0-indexed), add 1 to get the element value
       b[i].solved_element = std::countr_zero(b[i].potential_set) + 1;
       singletons          = true;
     }

examples/then.cpp

@@ -20,7 +20,7 @@
 
 #include <cstdio>
 
-///////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////
 // Example code:
 auto main() -> int
 {

include/._clangd_helper_file.cpp

@@ -14,18 +14,24 @@
  * limitations under the License.
  */
 
-// A file that sorts to the top of clangd's file list to help clangd infer the compile commands for nearby headers.
+// A file that sorts to the top of clangd's file list to help clangd infer the
+// compile commands for nearby headers.
 //
-// To provide intellisense when a user opens a header file, clangd searches the current dir, subdirs, and parent dirs
-// for nearby translation units. It sorts the list of nearby TUs, and uses the compile string of the first TU to
+// To provide intellisense when a user opens a header file, clangd searches the
+// current dir, subdirs, and parent dirs for nearby translation units. It sorts
+// the list of nearby TUs, and uses the compile string of the first TU to
 // provide intellisense for the opened header file.
 //
-// Clangd's heuristic is not perfect, but we can help it along. By starting this filename with an underscore, we
-// ensure it sorts to the top of the list of TUs.
+// Clangd's heuristic is not perfect, but we can help it along. By starting this
+// filename with an underscore, we ensure it sorts to the top of the list of
+// TUs.
 //
-// TUs closer to the header file in the directory tree are chosen before ones further up or down the directory tree,
-// therefore this file should be copied into any subdirectories with tranlation units whose compile flags are different
-// than those in the parent (for example, if the subdirectory has a CMakeList.txt that defines additional executables).
-// This ensures clangd provides useful intellisense for headers in any subdirectory with a CMakeList.txt.
+// TUs closer to the header file in the directory tree are chosen before ones
+// further up or down the directory tree, therefore this file should be copied
+// into any subdirectories with tranlation units whose compile flags are
+// different than those in the parent (for example, if the subdirectory has a
+// CMakeList.txt that defines additional executables). This ensures clangd
+// provides useful intellisense for headers in any subdirectory with a
+// CMakeList.txt.
 
 auto main() -> int {}

include/exec/__frame_allocator.hpp

@@ -26,24 +26,26 @@
 
 //! Defines template <class _Delegate> exec::__frame_allocator_t
 //!
-//! The intended use for __frame_allocator_t is the dynamic allocation of operation
-//! states and/or coroutine frames. __frame_allocator_t models the Allocator named
-//! requirement in terms of its type parameter, _Delegate.
+//! The intended use for __frame_allocator_t is the dynamic allocation of
+//! operation states and/or coroutine frames. __frame_allocator_t models the
+//! Allocator named requirement in terms of its type parameter, _Delegate.
 //!
 //! _Delegate may be one of:
-//!  - Another allocator, in which case __frame_allocator_t<_Delegate> is just _Delegate
-//!    rebound to std::byte;
-//!  - std::pmr::memory_resource*, in which case __frame_allocator_t<_Delegate> is just
-//!    std::pmr::polymorphic_allocator<std::byte>; or
-//!  - T* for some T that inherits from std::pmr::memor_resource, in which case
-//!    __frame_allocator_t is an allocator that behaves like
-//!    std::pmr::polymorphic_allocator<std::byte>, but knows the concrete type of its
-//!    memory_resource and so therefore may be able to avoid virtual dispatch.
+//! - Another allocator, in which case __frame_allocator_t<_Delegate> is just
+//!   _Delegate rebound to std::byte;
+//! - std::pmr::memory_resource*, in which case __frame_allocator_t<_Delegate>
+//!   is just std::pmr::polymorphic_allocator<std::byte>; or
+//! - T* for some T that inherits from std::pmr::memor_resource, in which case
+//!   __frame_allocator_t is an allocator that behaves like
+//!   std::pmr::polymorphic_allocator<std::byte>, but knows the concrete type of
+//!   its memory_resource and so therefore may be able to avoid virtual
+//!   dispatch.
 //!
-//! Given that __frame_allocator_t<_Delegate> is just an alias to _Delegate when _Delegate
-//! is an allocator type, it's up to that type whether its construct member function does
-//! "uses-allocator construction". When _Delegate is a pointer to a memory_resource,
-//! __frame_allocator_t<_Delegate>::construct does "uses-allocator construction".
+//! Given that __frame_allocator_t<_Delegate> is just an alias to _Delegate when
+//! _Delegate is an allocator type, it's up to that type whether its construct
+//! member function does "uses-allocator construction". When _Delegate is a
+//! pointer to a memory_resource, __frame_allocator_t<_Delegate>::construct does
+//! "uses-allocator construction".
 namespace experimental::execution
 {
   namespace __fa
@@ -55,8 +57,8 @@ namespace experimental::execution
 
     //! Handle the case that _Delegate is an allocator already
     //!
-    //! In this case, __frame_allocator_t<Delegate> is just an alias to _Delegate but
-    //! rebound to std::byte.
+    //! In this case, __frame_allocator_t<Delegate> is just an alias to
+    //! _Delegate but rebound to std::byte.
     template <class _Delegate>
       requires __simple_allocator<_Delegate>
     struct __frame_allocator<_Delegate>
@@ -79,10 +81,11 @@ namespace experimental::execution
     //! Handle the case that _Delegate is a pointer to a type that derives from
     //! std::pmr::memory_resource
     //!
-    //! In this case, __frame_allocator_t<_Delegate> is an allocator that behaves like
-    //! std::pmr::polymorphic_allocator<std::byte> except that it knows the concrete type
-    //! of its memory resource. In other words, allocation and deallocation are delegated
-    //! to the given resource, construct does uses-allocator construction, etc.
+    //! In this case, __frame_allocator_t<_Delegate> is an allocator that
+    //! behaves like std::pmr::polymorphic_allocator<std::byte> except that it
+    //! knows the concrete type of its memory resource. In other words,
+    //! allocation and deallocation are delegated to the given resource,
+    //! construct does uses-allocator construction, etc.
     template <class _Delegate>
       requires __std::derived_from<_Delegate, std::pmr::memory_resource>
     struct __frame_allocator<_Delegate *>
@@ -93,8 +96,8 @@ namespace experimental::execution
         using value_type = _Ty;
         using pointer    = value_type *;
 
-        // polymorphic_allocator's default constructor grabs the default memory resource,
-        // which we can't do because there's no default for _Delegate
+        // polymorphic_allocator's default constructor grabs the default memory
+        // resource, which we can't do because there's no default for _Delegate
 
         /*implicit*/ constexpr type(_Delegate *__resource) noexcept
           : __resource_(__resource)