new `get_completion_signatures impl` does not work when `__throw_compile_error` asserts or throws

[kirkshoop]

a new implementation of get_completion_signatures that improves diagnostics #1811

This new implementation uses __throw_compile_error in the evaluation of __completion_signatures_of_t which prevents concepts that use __completion_signatures_of_t from evaluating to false.

I added a static_assert to the __throw_compile_error impl for when constexpr exceptions are not supported by the compiler.

Some errors I think are correct and require changes to the tests - for instance:

[path]/stdexec/test/stdexec/concepts/test_concepts_sender.cpp:302:28: note: in instantiation of function template specialization '(anonymous namespace)::test_subsumption<std::execution::(anonymous namespace)::__sexpr<std::execution::(lambda at [path]/stdexec/include/stdexec/__detail/__basic_sender.hpp:56:53){}>>' requested here 
[path]/stdexec/include/stdexec/__detail/__completion_signatures.hpp:89:19: note: because '__mexception<_THE_CURRENT_EXECUTION_ENVIRONMENT_DOESNT_HAVE_A_VALUE_FOR_THE_GIVEN_QUERY_, _WHERE_ (_IN_ALGORITHM_, read_env_t), _WITH_QUERY_ (get_scheduler_t), _WITH_ENVIRONMENT_ (env<>)>' (aka '_ERROR_<std::execution::__read::_THE_CURRENT_EXECUTION_ENVIRONMENT_DOESNT_HAVE_A_VALUE_FOR_THE_GIVEN_QUERY_, std::execution::_WHERE_ (std::execution::_IN_ALGORITHM_, std::execution::__read::read_env_t), std::execution::_WITH_QUERY_ (std::execution::__queries::get_scheduler_t), std::execution::_WITH_ENVIRONMENT_ (std::execution::__env::env<>)>') does not satisfy '__ok'

Some errors I think are spurious and require changes to the implementation of get_completion_signatures - for instance:

Spurious Error Example

FAILED: [code=1] test/CMakeFiles/test.stdexec.dir/stdexec/algos/factories/test_read.cpp.o 
/usr/bin/c++ -DSTDEXEC_ENABLE_LIBDISPATCH -DSTDEXEC_NAMESPACE=std::execution -I[path]/stdexec/include -I[path]/stdexec/build-m1/include -I[path]/stdexec/build-m1/_deps/catch2-src/single_include -I[path]/stdexec/test -O3 -DNDEBUG -std=gnu++2b -arch arm64 -Wall -Werror=unused-parameter -ferror-limit=0 -fmacro-backtrace-limit=0 -ftemplate-backtrace-limit=0 -MD -MT test/CMakeFiles/test.stdexec.dir/stdexec/algos/factories/test_read.cpp.o -MF test/CMakeFiles/test.stdexec.dir/stdexec/algos/factories/test_read.cpp.o.d -o tes
t/CMakeFiles/test.stdexec.dir/stdexec/algos/factories/test_read.cpp.o -c [path]/stdexec/test/stdexec/algos/factories/test_read.cpp
In file included from [path]stdexec/test/stdexec/algos/factories/test_read.cpp:16:
In file included from [path]stdexec/include/stdexec/execution.hpp:22:
In file included from [path]stdexec/include/stdexec/__detail/__as_awaitable.hpp:21:
In file included from [path]stdexec/include/stdexec/__detail/__completion_signatures_of.hpp:21:
In file included from [path]stdexec/include/stdexec/__detail/__debug.hpp:20:
[path]/stdexec/include/stdexec/__detail/__completion_signatures.hpp:89:19: error: static assertion failed: compile-time error..
   89 |     static_assert(__ok<__mexception<_What...>>, "compile-time error..");
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
[path]/stdexec/include/stdexec/__detail/__completion_signatures.hpp:125:21: note: in instantiation of function template specialization 'std::execution::__throw_compile_time_error<std::execution::dependent_sender_error, std::execution::_WITH_SENDER_<std::execution::__basic_sender<std::execution::__read::read_env_t, std::execution::__queries::get_allocator_t>>>' requested here
  125 |     return STDEXEC::__throw_compile_time_error<_What...>();
      |                     ^
[path]/stdexec/include/stdexec/__detail/__get_completion_signatures.hpp:76:25: note: in instantiation of function template specialization 'std::execution::__throw_compile_time_error<std::execution::dependent_sender_error, std::execution::_WITH_SENDER_<std::execution::__basic_sender<std::execution::__read::read_env_t, std::execution::__queries::get_allocator_t>>>' requested here
   76 |         return STDEXEC::__throw_compile_time_error(_Completions());
      |                         ^
[path]/stdexec/include/stdexec/__detail/__get_completion_signatures.hpp:172:16: note: in instantiation of function template specialization 'std::execution::__cmplsigs::__checked_complsigs<std::execution::_ERROR_<std::execution::dependent_sender_error, std::execution::_WITH_SENDER_<std::execution::__basic_sender<std::execution::__read::read_env_t, std::execution::__queries::get_allocator_t>>>, std::execution::(anonymous namespace)::__sexpr<std::execution::(lambda at [path]/stdexec/include/stdexec/__detail/__basic_sender.hpp:56:53){}>>' requested here
  172 |         return STDEXEC_CHECKED_COMPLSIGS((_Sender), STDEXEC_GET_COMPLSIGS(_Sender));
      |                ^
[path]stdexec/include/stdexec/__detail/__get_completion_signatures.hpp:61:24: note: expanded from macro 'STDEXEC_CHECKED_COMPLSIGS'
   61 |   STDEXEC::__cmplsigs::__checked_complsigs(                                                        \
      | 
[path]stdexec/include/stdexec/__detail/__get_completion_signatures.hpp:237:24: note: in instantiation of function template specialization 'std::execution::__cmplsigs::__get_completion_signatures_helper<std::execution::(anonymous namespace)::__sexpr<std::execution::(lambda at [path]/stdexec/include/stdexec/__detail/__basic_sender.hpp:56:53){}>>' requested here
  237 |     return __cmplsigs::__get_completion_signatures_helper<_Sender>();
      |                        ^
[path]stdexec/include/stdexec/__detail/__sender_concepts.hpp:62:50: note: in instantiation of function template specialization 'std::execution::get_completion_signatures<std::execution::(anonymous namespace)::__sexpr<std::execution::(lambda at [path]/stdexec/include/stdexec/__detail/__basic_sender.hpp:56:53){}>>' requested here
   62 |     && __constant_completion_signatures<STDEXEC::get_completion_signatures<_Sender, _En
v...>()>;
      |                                                  ^
[path]stdexec/include/stdexec/__detail/__sender_concepts.hpp:62:8: note: while substituting template arguments into constraint expression here
   62 |     && __constant_completion_signatures<STDEXEC::get_completion_signatures<_Sender, _En
v...>()>;
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[path]stdexec/test/stdexec/algos/factories/test_read.cpp:30:20: note: while checking the satisfaction of concept 'sender_in<std::execution::(anonymous namespace)::__sexpr<std::execution::(lambda at [path]/stdexec/include/stdexec/__detail/__basic_sender.hpp:56:53){}>>' requested here
   30 |     static_assert(!ex::sender_in<Sndr>);
      |                    ^~~~~~~~~~~~~~~~~~~
[path]stdexec/include/stdexec/__detail/__completion_signatures.hpp:89:19: note: because '__mexception<dependent_sender_error, _WITH_SENDER_<__basic_sender<read_env_t, get_allocator_t>>>' (aka '_ERROR_<std::execution::dependent_sender_error, std::execution::_WITH_SENDER_<std::execution::__basic_sender<std::execution::__read::read_env_t, std::execution::__queries::get_allocator_t>>>') does not satisfy '__ok'
   89 |     static_assert(__ok<__mexception<_What...>>, "compile-time error..");
      |                   ^
[path]stdexec/include/stdexec/__detail/__meta.hpp:201:18: note: because '__is_same(__ok_t<_ERROR_<dependent_sender_error, _WITH_SENDER_<__basic_sender<read_env_t, get_allocator_t> > > >, __msuccess)' evaluated to false
  201 |   concept __ok = STDEXEC_IS_SAME(__ok_t<_Arg>, __msuccess);
      |                  ^
[path]stdexec/include/stdexec/__detail/__config.hpp:425:32: note: expanded from macro 'STDEXEC_IS_SAME'
  425 | #  define STDEXEC_IS_SAME(...) __is_same(__VA_ARGS__)
      |                                ^
1 error generated.

[ericniebler]

I added a static_assert to the __throw_compile_error impl for when constexpr exceptions are not supported by the compiler.

i don't know why you needed to do this. __throw_compile_time_error has two implementations to accommodate compilers that do not have compile-time exceptions (all of them, at the moment!).

tip of trunk is green. everything seems to be working as i intended. i don't know how you are getting these errors. can you pls post a repro?

[kirkshoop]

I was changing assert_with to use __throw_compile_time_error instead of static_assert, but I wasn't using a compiler that supports constexpr exceptions, so nothing happened when the assert_with failed.

Maybe I am not clear on what happens when a constexpr exception is thrown. I do not expect a constexpr exception to do nothing, which is what the existing __throw_compile_time_error does. I would expect that a static_assert is the closest analog to a constexpr exception when they are not supported.

I chose to add static_assert in __throw_compile_time_error in order for assert_with to report the failure in the absence of constexpr exceptions.

Does the CI have a matrix item that tests that constexpr exception usage in stdexec is working as expected?

Here is the repro:

  template <class, class... _What, class... _Values>
  [[nodiscard]]
  consteval auto __throw_compile_time_error_r(_Values...) -> __mexception<_What...> {
+    static_assert(__ok<__mexception<_What...>>, "compile-time error..");
    return {};
  }

  template <class... _What, class... _Values>
  [[nodiscard]]
  consteval auto __throw_compile_time_error(_Values...) -> __mexception<_What...> {
+    static_assert(__ok<__mexception<_What...>>, "compile-time error..");
    return {};
  }

[ericniebler]

__throw_compile_time_error isn't the tool you want, and putting static asserts there defeats its purpose.

Does the CI have a matrix item that tests that constexpr exception usage in stdexec is working as expected?

no because there is no such compiler yet, but i verified it manually using an experimental compiler on godbolt. ofc, i may have introduced bugs since then.

Maybe I am not clear on what happens when a constexpr exception is thrown. I do not expect a constexpr exception to do nothing, which is what the existing __throw_compile_time_error does.

it doesn't do exactly nothing. when constexpr exceptions are not available, it returns an __mexception object that describes the error. that error needs to be propagated manually. the utilities for manipulating completion signatures know about this detail and see that it is taken care of.

stdexec is in an inconsistent state right now with regards to get_completion_signatures. many of them are pure metaprograms that will not throw exceptions even when that's enabled. all of those metaprograms need to be converted to consteval functions that call return __throw_compile_time_error< ...what... >() on type errors.

really its all a bit of a mess at the moment. it's admittedly confusing.

EDIT: oh, and connect is another matter. type errors typically turn up naturally while computing completion signatures. by the time you're calling connect, it really should Just Work. ofc sometimes it doesn't, but that's almost always because of a bug in the sender implementation. it's a problem for people authoring sender algorithms, not the average Joe just trying to use the algorithms. since only algorithm authors are going to see errors at connect time, i don't bother trying to propagate errors from connect like i do for get_completion_signatures. algorithm authors often need to see the whole instantiation backtrace and why the compiler didn't pick the connect overload that they just wrote.