Remove type alias sender completions support (#6624) #6853

guptapratykshh · 2026-01-19T09:21:22Z

Proposed Changes

Removed the has_completion_signatures trait and the fallback logic supporting nested type aliases in get_completion_signatures.
Updated any_sender and unique_any_sender to expose completion signatures via tag_invoke exclusively.
Refactored unit tests (basic_sender, basic_schedule, coroutine_utils, etc.) to replace nested aliases with the standard tag_invoke pattern.

Any background context you want to provide?

This change aligns with the recent WG21 decision (P3164) to eliminate the option of a nested completion_signatures type alias in favor of relying solely on the get_completion_signatures customization point object.

Checklist

Not all points below apply to all pull requests.

I have added a new feature and have added tests to go along with it.
I have fixed a bug and have added a regression test.
I have added a test using random numbers; I have made sure it uses a seed, and that random numbers generated are valid inputs for the tests.

StellarBot · 2026-01-19T09:25:04Z

Can one of the admins verify this patch?

krisha-9 · 2026-01-19T17:58:06Z

I went through the CI failures, especially clang_format. The PR modifies multiple files with tag_invoke(get_completion_signatures_t, …) blocks (e.g. any_sender.hpp and related tests), and running clang-format locally on the changed files produces formatting diffs. This seems to be the reason for the failing clang_format check. Formatting the modified files should make this check pass.

hkaiser · 2026-01-19T20:12:18Z

I went through the CI failures, especially clang_format. The PR modifies multiple files with tag_invoke(get_completion_signatures_t, …) blocks (e.g. any_sender.hpp and related tests), and running clang-format locally on the changed files produces formatting diffs. This seems to be the reason for the failing clang_format check. Formatting the modified files should make this check pass.

Yes, reformatting those files using clang-format v20 should fix both, the reported issues from clang-format and inspect.

hkaiser · 2026-01-19T20:13:12Z

There are however some build failures as reported by CirclCI, please have a look.

hkaiser · 2026-01-20T16:05:02Z

You can ignore the problems reported for the ci/circleci: tests.unit1.container_algorithms step. The compilation errors reported by ci/circleci: tests.unit3 seem to be caused by this PR, though.

codacy-production · 2026-01-21T20:04:38Z

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for `18a5e6e`¹	✅ 0.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (`18a5e6e`)	Report Missing	Report Missing	Report Missing
Head commit (`4bbb754`)	134738	51	0.04%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#6853)	9	0	0.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings Change summary preferences

Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

hkaiser · 2026-01-22T12:27:36Z

FWIW, the MacOS errors look like a missing #include statement.

hkaiser · 2026-02-03T15:51:01Z

examples/1d_stencil/1d_stencil_8.cpp

 {
 private:
-    typedef hpx::spinlock mutex_type;
+    typedef std::mutex mutex_type;


Using std::mutex from HPX threads is generally not a good idea. This will stop the scheduler that runs on the thread aquiring the lock. This change 'fixes' the issue you are seeing only by coincidence as it changes the overall timing of the task executions.

hkaiser · 2026-02-03T15:53:16Z

examples/1d_stencil/1d_stencil_8.cpp

+{
+    static partition_allocator<double>* alloc =
+        new partition_allocator<double>();
+    return *alloc;


Why did you decide to allocate the allocator on the heap (and where is it free'd)? Wouldn't a simple

static partition_allocator<double> alloc{}; return alloc;

suffice?

hkaiser · 2026-02-03T15:57:40Z

libs/core/execution_base/include/hpx/execution_base/completion_signatures.hpp

+            if constexpr (requires {
+                              typename std::decay_t<
+                                  Sender>::completion_signatures;
+                          })


If detail::has_completion_signatures_v<Sender> causes issues (probably because it attempts to instantiate things that shouldn't be instantiated), wouldn't it be a better solution to fix it's implementation? For instance:

template <typename Sender> inline constexpr bool has_completion_signatures_v = requires { typename std::decay_t<Sender>::completion_signatures; };

?

hkaiser · 2026-02-03T16:07:08Z

examples/quickstart/1d_wave_equation.cpp

+    if (vm.count("c-value"))
+        c = vm["c-value"].as<double>();
+    else
+        c = 1.0;


The default value is always 1.0, I don't think the else will be ever executed.

hkaiser · 2026-02-03T16:11:28Z

libs/core/futures/include/hpx/futures/traits/detail/future_await_traits.hpp

+    {
+        f.get();
+    }
+


This could be simplified by using void_guard (see https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/type_support/include/hpx/type_support/void_guard.hpp). However I don't see why the separate handling of void would be necessary in the first place. Did you see issues with this?

hkaiser · 2026-02-03T16:13:12Z

examples/quickstart/1d_wave_equation.cpp

+        "Nt value")("c-value", value<double>()->default_value(1.0), "c value")(
+        "dt-value", value<double>()->default_value(1.0),
+        "dt value")("dx-value", value<double>()->default_value(1.0),
+        "dx value");


Could leave this unformatted, please?

hkaiser · 2026-02-03T16:14:48Z

libs/core/execution/include/hpx/execution/algorithms/when_all.hpp

+            std::conjunction<std::negation<hpx::traits::is_future<Sender>>,
+                is_sender<Sender>>,
+            std::conjunction<std::negation<hpx::traits::is_future<Senders>>,
+                is_sender<Senders>>...>)>


You may be able to write this as a 'real' requires() clause.

hkaiser · 2026-02-03T16:15:44Z

libs/core/execution/include/hpx/execution/algorithms/when_all.hpp

+                Env) noexcept -> generate_completion_signatures<Env>
+            {
+                return {};
+            }


The implementation shouldn't be necessary as the function will never be actually executed. It is ever only used for type computations (i.e. in unevaluated contexts).

hkaiser · 2026-02-03T16:16:28Z

libs/full/async_distributed/tests/regressions/components/CMakeLists.txt

  action_move_semantics_component
 )
+
+hpx_set_lib_name(action_move_semantics_component action_move_semantics_test)


Why is this necessary?

Signed-off-by: guptapratykshh <[email protected]>

guptapratykshh requested a review from hkaiser as a code owner January 19, 2026 09:21

guptapratykshh force-pushed the remove_completion_signatures_alias branch from 7976eed to 968c14c Compare January 19, 2026 11:22

hkaiser added type: enhancement type: compatibility issue category: executors labels Jan 19, 2026

guptapratykshh force-pushed the remove_completion_signatures_alias branch 4 times, most recently from ba53269 to 9fc5e83 Compare January 21, 2026 17:58

guptapratykshh force-pushed the remove_completion_signatures_alias branch 14 times, most recently from bca150d to e4c1dc7 Compare January 24, 2026 06:52

guptapratykshh force-pushed the remove_completion_signatures_alias branch 13 times, most recently from 0a00463 to 53bda2a Compare February 2, 2026 07:59

hkaiser reviewed Feb 3, 2026

View reviewed changes

guptapratykshh force-pushed the remove_completion_signatures_alias branch 3 times, most recently from 8923653 to b47f78c Compare February 4, 2026 14:51

guptapratykshh added 4 commits February 4, 2026 20:23

Fix data race in 1d_wave_equation and MacOS build issue

f7c4987

Signed-off-by: guptapratykshh <[email protected]>

fix: when_all compilation and 1d_wave example timeout

e972b9b

Signed-off-by: guptapratykshh <[email protected]>

Fix completion_signatures check and suppress use-after-move warnings

91fced1

Signed-off-by: guptapratykshh <[email protected]>

Re-apply 1d_stencil_8 Fix: Use std::mutex and leaked allocator singleton

9306260

Signed-off-by: guptapratykshh <[email protected]>

guptapratykshh force-pushed the remove_completion_signatures_alias branch from b47f78c to 9306260 Compare February 4, 2026 14:53

Uh oh!

Remove type alias sender completions support (#6624) #6853

Are you sure you want to change the base?

Remove type alias sender completions support (#6624) #6853

Conversation

guptapratykshh commented Jan 19, 2026

Proposed Changes

Any background context you want to provide?

Checklist

Uh oh!

StellarBot commented Jan 19, 2026

Uh oh!

krisha-9 commented Jan 19, 2026

Uh oh!

hkaiser commented Jan 19, 2026

Uh oh!

hkaiser commented Jan 19, 2026

Uh oh!

hkaiser commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codacy-production bot commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage summary from Codacy

Footnotes

Uh oh!

hkaiser commented Jan 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hkaiser Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hkaiser Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

hkaiser commented Jan 20, 2026 •

edited

Loading

codacy-production bot commented Jan 21, 2026 •

edited

Loading

hkaiser Feb 3, 2026 •

edited

Loading

hkaiser Feb 3, 2026 •

edited

Loading