`STDEXEC_ENABLE_EXTRA_TYPE_CHECKING` no longer checks senders in `connect` (since #1809)

Offen
#2,407 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
cmake, cpp

Rechercherichtung

The check lives in connect_t::operator() and the debug receiver __debug::__receiver. The any_sender failure is in test/exec/test_any_sender.cpp, at the __nothrow_move_constructible assert in __fwd in __env.hpp. The CMake SYSTEM include setting is the other part. First the maintainers must decide whether the flag should keep working. If it should, done means the mismatched-completion case warns through connect, the any_sender test compiles with the flag on, and a build-failure test exists.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

With STDEXEC_ENABLE_EXTRA_TYPE_CHECKING, connect used to instantiate completion_signatures_of_t for the sender it connects, so __debug_sender warned when a sender completes with something it did not declare. That came from #1070 (for #1065). The new connect from #1809 no longer does this, so now only code that names completion_signatures_of_t gets the check.

Example: a sender that declares set_value_t(int) but completes with set_value(std::move(rcvr), v), where v is an int lvalue. Compiled with -I<stdexec>/include -DSTDEXEC_ENABLE_EXTRA_TYPE_CHECKING, with GCC 12 and Clang 21:

sync_wait(sndr) let_value(sndr, f) completion_signatures_of_t<Sndr>
before #1809 (6d568715~1) warning warning warning
#1809 and main (e780d360) no warning no warning warning

I tried to put the check back into connect_t::operator(), and found two more things:

  • With the flag on, that breaks test/exec/test_any_sender.cpp with GCC 12 and Clang 21. when_any inside an any_sender then gets connected to __debug::__receiver, and static_assert(__nothrow_move_constructible<_Env>) in __fwd (__env.hpp) fails for the type-erased receiver environment. Main compiles that file with the flag on.
  • Since ca3797c3, the CMake target adds the include directory as SYSTEM. GCC and Clang don't report warnings from system headers, so with -isystem instead of -I none of the cases above warn, also before #1809. So CMake users don't see these warnings at all.

Is the flag still meant to work? If yes, I'd be happy to make a PR that restores the check in connect, makes it work with any_sender, and adds a build-failure test. For the SYSTEM part, one option is to not mark the include directory SYSTEM when STDEXEC_ENABLE_EXTRA_TYPE_CHECKING is ON. If you'd rather drop the flag, that's fine too.

Claude (Anthropic) was used as assistant.

Vorherrschende Sprache
C++
Sterne
2.5k
Forks
285
Ø Merge
2 T. 5 Std.
Gemergte PRs (30 T.)
85

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NVIDIA/stdexec

Alle Issues in NVIDIA/stdexec

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.