stdexec::env supports a restrictively small number of properties when created from a brace initialized list with CL.exe #1979
Description
When using stdexec to construct an environment with a moderate number of properties the library runs into compiler limits using CL.exe. The following example can be run against CL.exe from the visual studio command prompt (reduced from a larger project).
cl.exe example.cpp -Ithirdparty/stdexec/include/ /std:c++latest /Zc:preprocessor /Zc:__cplusplus
where example.cpp is the contents of the proceeding file and thirdparty/stdexec/include/ is the include files for stdexec.
#include <stdexec/execution.hpp>
#define DEFINE_ENVIRONMENT_FUNCTION(name)\
struct name##_fn\
{\
auto operator()(const auto& env) const noexcept -> decltype(env.query(*this))\
{\
return env.query(*this);\
}\
};\
inline constexpr name##_fn name{}
DEFINE_ENVIRONMENT_FUNCTION(test0);
DEFINE_ENVIRONMENT_FUNCTION(test1);
DEFINE_ENVIRONMENT_FUNCTION(test2);
DEFINE_ENVIRONMENT_FUNCTION(test3);
DEFINE_ENVIRONMENT_FUNCTION(test4);
DEFINE_ENVIRONMENT_FUNCTION(test5);
DEFINE_ENVIRONMENT_FUNCTION(test6);
DEFINE_ENVIRONMENT_FUNCTION(test7);
DEFINE_ENVIRONMENT_FUNCTION(test8);
DEFINE_ENVIRONMENT_FUNCTION(test9);
auto main() -> int
{
auto x = stdexec::env{
stdexec::prop(test0, 0),
stdexec::prop(test1, 1),
stdexec::prop(test2, 2),
stdexec::prop(test3, 3),
stdexec::prop(test4, 4),
stdexec::prop(test5, 5),
stdexec::prop(test6, 6),
stdexec::prop(test7, 7),
stdexec::prop(test8, 8),
stdexec::prop(test9, 9)};
}This code will fail to compile with fatal error C1054: compiler limit: initializers nested too deeply. See C1054 & Compiler Limits for more information. The issue does not reproduce with fewer than 10 initializers. I was able to work around this problem by manually creating nested stdexec::env types so there were fewer than 10 at the top level. Using git bisect I discovered this was introduced in bcaaaf2. I ran into this when upgrading from nvhpc-25.09 to gtc-2026.
I am using Microsoft (R) C/C++ Optimizing Compiler Version 19.50.35728 for x64; I did not run into a similar issue on GNU GCC nor Clang-CL nor Clang (Linux).