inline_scheduler's namespace-scope static_assert fails under nvcc (private nested __sender access)

Vấn đề nằm trong __inline_scheduler.hpp, nơi một static_assert thất bại dưới nvcc do truy cập riêng tư. Hãy xem dòng static_assert gần cuối tệp. Hiểu kiểu __sender và khái niệm __completes_inline. Cách sửa là bảo vệ static_assert bằng #if !defined(CUDACC). Kiểm tra bằng cách biên dịch bản tái tạo tối thiểu với nvcc sau khi thay đổi.

Summary

Since inline_scheduler gained a private nested __sender type in f4ad47a6 (Aug 2025, P3552 promotion), the namespace-scope check at the bottom of __inline_scheduler.hpp fails to compile under nvcc:

static_assert(__completes_inline<set_value_t, env_of_t<schedule_result_t<inline_scheduler>>>);

error: 'struct stdexec::inline_scheduler::__sender' is private within this context

I know the README already notes stdexec doesn't yet support nvcc, so I'm filing this mainly for visibility/discussion rather than expecting it to be treated as a supported-configuration bug. I also found a closely analogous case in googletest (#4104, "NVCC, lambdas and private TestBody"), where the maintainers closed a very similar report as a compiler bug in an unsupported toolchain and declined to work around it. If the answer here is the same, that's completely understandable, just wanted to put the specific case in front of you in case a narrow guard is welcome.

Repro

Any translation unit compiled with nvcc that transitively includes <stdexec/execution.hpp> hits this, since the assert is unconditional and evaluated at header-parse time, not on first use. Minimal repro:

#include <stdexec/execution.hpp>
int main() {}

Compiled with:

nvcc -std=c++20 --extended-lambda -x cu -c repro.cpp

Environment

• CUDA 12.9.86 / nvcc
• GCC 12.2.1 host compiler
• stdexec main (currently)

Where we hit it

Via HPX (TheHPXProject/hpx), whose hpx/execution.hpp pulls in stdexec/execution.hpp directly. Any .cu test that reaches HPX's execution headers now fails on this. HPX's own recent pattern for this class of issue has been to stop compiling HPX-execution-adjacent code with nvcc at all, splitting kernel-only .cu files from host-side .cpp. That's a reasonable structural fix on our end regardless of what happens here, but this particular failure is narrow enough that it seemed worth raising in case a small guard has value.

Question for maintainers

Since this is a compile-time-only sanity check with no runtime behavior, would a guard like

#if !defined(__CUDACC__)
  static_assert(__completes_inline<set_value_t, env_of_t<schedule_result_t<inline_scheduler>>>);
#endif

be something you'd consider, or would you rather leave this alone given nvcc is explicitly out of scope right now? Either way is fine, just wanted to surface the specific case.