conditionally contribute set_error_t(std::exception_ptr) in repeat_* senders

[justend29]

Currently, the repeat_ family of sender adapters invariantly contributes set_error_t(std::exception_ptr) to its completion signatures, which I first mentioned in this issue. This PR causes repeat_until, repeat, and repeat_n to conditionally contribute set_error_t(std::exception_ptr) to the completion signatures. Each of the possible cases (not) to contribute the completion signature are individually tested.

It also contains some small corrections that were originally in #1797, until @RobertLeahy informed me that it is possible to detect the noexcept-ness of a connect using STDEXEC::__receiver_archetype<Env>, wherein I returned to this original goal.

This is also my first time working with the meta-programming system in this library, so feedback is welcome.

[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.

[justend29]

Thank you for the review, @ericniebler. All of your comments have been addressed, though __partition_completion_signatures_t was changed to __partitions_of_t to compile.

[ericniebler]

/ok to test ac8352c

[ericniebler]

/ok to test 99cf087

[justend29]

@ericniebler It's odd that the CI jobs using an older version of GCC fail while the other CI jobs pass. I tested everything with GCC15.2.1 locally. I'm not sure if you have any ideas, but I can probably install an older version of GCC and try to reproduce the failing build locally over the weekend.

[ericniebler]

It's odd that the CI jobs using an older version of GCC fail while the other CI jobs pass.

that's business as usual. getting CI to pass with older, less-conforming compilers is often the majority of the work for PRs. i wish things were different.

[justend29]

Two competing compiler issues were found that I'll document for future reference:

Firstly, older versions of GCC delete arguments to function signatures in type traits and concepts - at least from compiler errors. For example (note the _Tp = int(), _Up = int()):

static_assert(std::same_as<int(char, double), int(double, char)>);

test.cpp:21:22: note: constraints not satisfied
In file included from test.cpp:1:
/usr/include/c++/11/concepts:57:15:   required for the satisfaction of ‘__same_as<_Tp, _Up>’ [with _Tp = int(); _Up = int()]
/usr/include/c++/11/concepts:57:32: note: the expression ‘is_same_v<_Tp, _Up> [with _Tp = int(); _Up = int()]’ evaluated to ‘false’
   57 |       concept __same_as = std::is_same_v<_Tp, _Up>;
      |                           ~~~~~^~~~~~~~~~~~~~~~~~~

This made it incredibly hard to debug a test for completion signatures, as every static_assert to check a subset of the problem involves a function signature that the compiler would erase the arguments of.

Secondly, using = default on a constructor disregards its noexcept(false) specifier with the older compilers. This ended up being the main culprit after being sent for a loop from the above. Removing =default seems to be all that was necessary to compile with GCC11.

Should there be further compiler conformance issues in CI, I'll address those, too.