MSVC compilation fails in header mode due to requires evaluation bug in get_completion_signatures_for_helper

[ecoezen]

when building the package on msvc with module disabled, compilation fails during tests (e.g. exec-associate.test.cpp) with constrain satisfaction error for sender_in/completion_signatures_of_t. when modules enabled, code compiles flawlessly.

Build Logs (Short)

󰍲 ecoezen in  …\execution on  main +0 -0
╰─❯ cmake --preset msvc-debug -DBEMAN_USE_MODULES=OFF -DBEMAN_USE_STD_MODULE=OFF
-- The CXX compiler identification is MSVC 19.50.35724.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.50.35717/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES=
-- BEMAN_USE_MODULES=OFF
-- BEMAN_USE_STD_MODULE=OFF
-- CMAKE_CXX_SCAN_FOR_MODULES=OFF
CMake Warning at cmake/beman-install-library.cmake:159 (message):
beman_install_library(beman.execution): 'beman.execution' is not a target
Call Stack (most recent call first):
CMakeLists.txt:112 (beman_install_library)

-- Configuring done (1.4s)
-- Generating done (0.5s)
-- Build files have been written to: C:/Users/ecoezen/Repositories/execution/build/msvc-debug

󰍲 ecoezen in  …\execution on  main +0 -0
╰─❯ cmake --build --preset msvc-debug
[12/224] Building CXX object tests\beman\execution\CMakeFi...ecution.exec-associate.test.dir\exec-associate.test.cpp.ob
FAILED: [code=2] tests/beman/execution/CMakeFiles/beman.execution.exec-associate.test.dir/exec-associate.test.cpp.obj
C:\PROGRA1\MICROS1\18\COMMUN1\VC\Tools\MSVC\14501.357\bin\Hostx64\x64\cl.exe /nologo /TP -IC:\Users\ecoezen\Repositories\execution\tests\beman\execution\include -IC:\Users\ecoezen\Repositories\execution\include /DWIN32 /D_WINDOWS /EHsc /EHsc /permissive- /fsanitize=address /Zi /Zi /Ob0 /Od /RTC1 -std:c++latest -MDd /showIncludes /Fotests\beman\execution\CMakeFiles\beman.execution.exec-associate.test.dir\exec-associate.test.cpp.obj /Fdtests\beman\execution\CMakeFiles\beman.execution.exec-associate.test.dir\ /FS -c C:\Users\ecoezen\Repositories\execution\tests\beman\execution\exec-associate.test.cpp
C:\Users\ecoezen\Repositories\execution\tests\beman\execution\exec-associate.test.cpp(120): error C7602: 'beman::execution::completion_signatures_of_t': the associated constraints are not satisfied
C:\Users\ecoezen\Repositories\execution\include\beman/execution/detail/completion_signatures_of_t.hpp(30): note: see declaration of 'beman::execution::completion_signatures_of_t'
C:\Users\ecoezen\Repositories\execution\include\beman/execution/detail/completion_signatures_of_t.hpp(28): note: the concept 'beman::execution::sender_in<main::snd0_t,beman::execution::env<>>' evaluated to false
C:\Users\ecoezen\Repositories\execution\include\beman/execution/detail/sender_in.hpp(36): note: the concept 'beman::execution::detail::valid_completion_signaturesbeman::execution::detail::no_completion_signatures_defined_in_sender' evaluated to false
C:\Users\ecoezen\Repositories\execution\include\beman/execution/detail/valid_completion_signatures.hpp(28): note: the constraint was not satisfied
C:\Users\ecoezen\Repositories\execution\include\beman/execution/detail/sender_in.hpp(35): note: the expression was resolved to a call to 'beman::execution::get_completion_signatures_t::operator ()'
C:\Users\ecoezen\Repositories\execution\include\beman/execution/detail/get_completion_signatures.hpp(75): note: see declaration of 'beman::execution::get_completion_signatures_t::operator ()'
C:\Users\ecoezen\Repositories\execution\tests\beman\execution\exec-associate.test.cpp(119): error C2882: 'std': illegal use of namespace identifier in expression
[35/224] Building CXX object tests\beman\execution\CMakeFi...ecution.exec-affine-on.test.dir\exec-affine-on.test.cpp.ob
ninja: build stopped: subcommand failed.

it seems the failure stems from msvc bug regarding requires expressions containing dependent types.

Fix:

changing completion_signatures_for.hpp from

template <typename Sender, typename... Env>
constexpr auto get_completion_signatures_for_helper() {
    using tag_t = ::std::remove_cvref_t<::beman::execution::tag_of_t<::std::remove_cvref_t<Sender>>>;
    // MSVC BUG?: incorrectly evaluates`requires` constraints containing dependent types as FALSE,
   // when they are evaluated *inside a function template body*.
    if constexpr (requires { tag_t::template get_completion_signatures<Sender, Env...>(); })
        return tag_t::template get_completion_signatures<Sender, Env...>();
    else
        return ::beman::execution::detail::no_completion_signatures_defined_in_sender{};
}

template <typename Sender, typename... Env>
using completion_signatures_for = decltype(get_completion_signatures_for_helper<Sender, Env...>());

to the classical SFINAE partial template specialization:

template <typename Tag, typename Sender, typename... Env>
struct get_completion_signatures_for_impl {
    using type = ::beman::execution::detail::no_completion_signatures_defined_in_sender;
};

template <typename Tag, typename Sender, typename... Env>
    requires requires { Tag::template get_completion_signatures<Sender, Env...>(); }
struct get_completion_signatures_for_impl<Tag, Sender, Env...> {
    using type = decltype(Tag::template get_completion_signatures<Sender, Env...>());
};

template <typename Sender, typename... Env>
using completion_signatures_for = typename get_completion_signatures_for_impl<
    ::std::remove_cvref_t<::beman::execution::tag_of_t<::std::remove_cvref_t<Sender>>>,
    Sender,
    Env...>::type;

since it seems we're not currently testing header builds explicitly for any supported toolchains in CI, a PR for this fix won't be covered by automated testing or have any meaningful observability moving forward. should we add a dedicated CI matrix for header builds, or we should consider header builds as 'best effort' so i'd send a blind PR that i tested locally?

[ClausKlein]

@dietmarkuehl We should change the module to Daniela's advice as I do in scope.

Than we can test with header only interface lib, but we need to add some smoke tests with the module lib!

[ClausKlein]

@ecoezen should we test with current MSVC too?

see bemanproject/infra#26

[ecoezen]

@ecoezen should we test with current MSVC too?

see bemanproject/infra#26

I think we should eventually do, considering nature of bemanproject that requires bleeding-edge dependencies on toolchains. i locally test with both VS2022 and VS2026 tho.

[ecoezen]

@dietmarkuehl We should change the module to Daniela's advice as I do in scope.

Than we can test with header only interface lib, but we need to add some smoke tests with the module lib!

if we still have to write the code in hpp files, not only cppm files, then we should test it. otherwise, why we bother with headers in this codebase at all! I am actually pro-modules, would like to ditch headers completely and dont want to see the word 'include' and the extension 'h/hpp' anymore.

interestingly, last night i saw committe panel discussion at cppcon, where @JeffGarland states, "beman project definitely interested in being module first". i wish that was real, so someone in this ecosystem were brave enough to ditch headers at scale. consecutively, we can get rid of decades of "header-only workaround" for our beloved language.

[ClausKlein]

@ecoezen what do you think about this: ClausKlein/asio#5

Clang 22.1 has a significantly more complete C++20/23 modules implementation than GCC 15, especially in these areas:

• private module fragments
• module ownership consistency
• friend injection across module partitions
• header-unit interactions
• P1689 dependency scanning
• module + textual include interop

So the fact that Clang builds it fine is not surprising.

Why Clang Accepts It

Clang’s modules implementation is:

1. More permissive with legacy header patterns
2. More robust with mixed textual + modular builds
3. Fully implements module :private;
4. Handles redeclarations across global/module fragments more gracefully

GCC, by contrast:

• Is stricter about ownership rules
• Still has unimplemented module features
• Treats some header-originated declarations as conflicting module entities

[ecoezen]

@ecoezen what do you think about this: ClausKlein/asio#5

if Daniela's advice is to use headers for developing and including all hpp files (and include cpp files in :private module fragment, if there is any), i completely support this. if this project aims to support both modes, i think the best strategy is 'abi breaking style' module transition, well written here. this means we are not module first, but at least we wont have the pain. having 1o1 module files and hpp files create problems imo, including :

1. slower compile times: my initial experince with modules tells me that include a header file in a module make things slower than header only setups, when building your own library. so one should choose either header, or module. should avoid mixed setups at all cost.

2. language server problems.. i am experiencing problems with clangd. it mix things up when we have both headers and cppm files together. i tend to disable modules and build bemanproject/execution with headers when working on it.

Clang 22.1 has a significantly more complete C++20/23 modules implementation than GCC 15, especially in these areas: ...

regarding your comparison above; I am not a regular gcc user, so can't tell the progress over there. but for clang and msvc, i believe clang got better than msvc recently. i am looking for proper clang-cl module support in cmake so i can keep myself avoiding msvc as usual and stick with clang/clang-cl pair. in short, clang shows better progress imo.

[dietmarkuehl]

I don't know what "Daniela's advice" is. I'm willing to support modules (and I have invested quite a bit of time to have them for execution) but until all systems ship with a module aware compiler I'm unwilling to drop header support! My stance remains that it shall be easy to trying things out on a system without any installation beyond the basic build support, ideally using the "obvious" build instruction. In may mind that amount to typeing make on POSIX system - which can, if necessary, invoke cmake. Sadly, cmake and ninja are also tools which are not standard and I think they are needed to build execution.

That said, I don't think this discussion belong into an issue of one of the repositories.