`STDEXEC_ENABLE_EXTRA_TYPE_CHECKING` no longer checks senders in `connect` (since #1809)
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- cmake, cpp
- 領域
- build-system, devtools
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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.cppwith GCC 12 and Clang 21.when_anyinside anany_senderthen gets connected to__debug::__receiver, andstatic_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-isysteminstead of-Inone 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.
- 主要言語
- C++
- スター
- 2.5k
- フォーク
- 284
- 平均マージ
- 2日 5時間
- マージ済み PR（30日）
- 85
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA/stdexec のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
NVIDIA/stdexec#1751 · コメント 3 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 4/5 1週間以上 初心者へのやさしさ 18/100
メンテナーはふだん 2 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 18/100
NVIDIA/stdexec#2402 · コメント 3 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 3/5 1〜3時間 初心者へのやさしさ 25/100
NVIDIA/stdexec#2400 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
NVIDIA/stdexec#2344 · コメント 4 件 ·
メンテナーはふだん 2 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
NVIDIA-RTX/NRI#312 ·
メンテナーはふだん 1 日以内に返信
-
permute_q_b_proj / permute_wv_proj accept scale factors from another device対応中かも @0z5a が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
deepseek-ai/FlashMLA#247 ·
メンテナーはふだん 1 日以内に返信
-
Linux npm packaging leaves workspace files that block subsequent CI checkout対応中かも @Spockkk0225 が今日担当しました。 オープンci
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
alibaba/neug#1195 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 3 日以内に返信