fix: provide the scheduler_concept nested alias on all stdexec schedulers (#2134)

[alwaysprince05]

Fixes #2134

What happened

Users couldn't start an exec::task on an exec::static_thread_pool or exec::timed_thread_context scheduler — the code failed to compile:

include/exec/task.hpp:163:33: error: no viable overloaded '='

The task's internal __any_scheduler converting constructor is guarded by __semi_scheduler, which requires a scheduler_concept typedef derived from scheduler_tag. Per [exec.sched], that nested alias is part of the scheduler concept, so scheduler types are expected to define it — but a number of the schedulers in stdexec did not.

The fix (updated after review)

Rather than loosening the internal __semi_scheduler concept (the original approach of this PR), this PR now keeps include/exec/task.hpp exactly as it is on main and instead makes all of stdexec's own schedulers provide the required nested alias (using scheduler_concept = scheduler_tag;):

• exec::static_thread_pool::scheduler
• exec::thread_pool_base<...>::scheduler (also covers exec::tbb::tbb_thread_pool and exec::taskflow::taskflow_thread_pool)
• exec::timed_thread_scheduler
• exec::libdispatch_scheduler
• exec::io_uring_context::__scheduler (Linux)
• exec::windows_thread_pool::scheduler (Windows)
• exec::trampoline_scheduler's scheduler
• exec::reschedule's internal scheduler
• stdexec::parallel_scheduler
• nvexec::stream_scheduler and nvexec::multi_gpu_stream_scheduler

Schedulers that already defined the alias are unchanged (inline_scheduler, run_loop's scheduler, any_scheduler, and the test-common schedulers).

Tests

Two regression tests in test/exec/test_task.cpp co_start an exec::task on exec::static_thread_pool and exec::timed_thread_context and verify it actually runs, guarding the fix going forward.

Verification

• test.exec: 3401 assertions / 359 cases pass (Release, Apple Clang)
• test.stdexec: 3528 assertions / 619 cases pass

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[alwaysprince05]

Hi @ericniebler — could you run /ok to test 1551bbb when you get a chance? It's a small fix for #2134: it drops the scheduler_concept requirement from __semi_scheduler so exec::task can be co_started on exec::static_thread_pool and exec::timed_thread_context, plus two compile-time regression tests. Details in the description. Thanks!

[ericniebler]

The scheduler concept requires the scheduler_concept nested alias. See [exec.sched]. I think the right fix here is for all of the schedulers in stdexec to provide that nested alias.

[alwaysprince05]

Good point — done. 2a5cf76 restores __semi_scheduler (and all of include/exec/task.hpp) to exactly what is on main, and instead adds the scheduler_concept nested alias required by [exec.sched] to the schedulers in stdexec that were missing it: static_thread_pool, thread_pool_base (covers the tbb and taskflow pools), timed_thread_scheduler, libdispatch_scheduler, io_uring_context, windows_thread_pool, trampoline_scheduler, reschedule, parallel_scheduler, and the nvexec stream and multi-GPU stream schedulers. The two regression tests from the original PR are kept, and test.exec + test.stdexec pass.

[alwaysprince05]

(Squashed the two commits into a single clean one before review started; the fix described above is now commit 2c7dc69 — content is unchanged.)

[alwaysprince05]

Hi @ericniebler — the clang-format violations you'd have seen on the earlier head are fixed now (7b4b2c5, whitespace-only, verified against clang-format-21 exactly as CI runs it). Could you /ok to test so the workflows can run on the new commit? Thanks!

[ericniebler]

/ok to test 7b4b2c5

[alwaysprince05]

FYI: the failing CPU (clang 22, Debug, modules) job is the known-broken allow_failure: true config — it also fails on current main (example run). The errors are in test/stdexec/types/test_task.cpp, which this PR doesn't touch, so I believe it's unrelated.

[ericniebler]

thanks!