Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Helper __awaitable concept doesn't correctly handle await_transform

未关闭
#596 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
停滞
技术栈
cpp
领域
compilers

调研方向

从链接行附近的 include/coroutine.hpp 中的 __awaitable concept 开始,然后将其检查与所述的 coroutine 语义以及 std::generator promise_type 示例进行比较。确定该 concept 应如何考虑已声明的 await_transform 成员,以及所需的 compiler intrinsic 是否可用;完成的标准是该 concept 不再将无效的 co_await 表达式报告为 awaitable。

由索引模型根据 Issue 内容生成。

描述

bug P2

The coroutine semantics are such that if there is any member of the promise type declared as await_transform then the co_await expression inside a coroutine with that promise type will first call promise.await_transform().

The current concept just checks that the particular type being queried is callable with promise.await_transform(<expr>) and if that is not well-formed then it falls back to just checking if <expr> has a valid operator co_await().

This could result in incorrectly reporting that a type satisfies __awaitable<Promise> when a co_await expression with an operand of that type would be ill-formed.

e.g. The current logic would indicate that std::suspend_always satisfies the __awaitable<std::generator<int>::promise_type> concept, despite co_await expressions being ill-formed inside std::generator coroutines.

Note that it's not currently possible to exactly match the behaviour of the compiler in library alone.
There would need to be some intrinsic for asking the compiler whether a given promise type has any member named 'await_transform' declared.

主要语言
C++
星标
2.4k
派生
270
平均合并
2 天 16 小时
30 天内合并 PR
43

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

NVIDIA/stdexec 的其他 Issue

查看 NVIDIA/stdexec 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。