feat: Add Generator

[4kangjc]

Why

#103

TODO:
add documents

What is changing

Example

[ChuanqiXu9]

因为 Generator 已经进入 C++标准了：https://github.com/cplusplus/papers/issues/1151
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2502r2.pdf
所以要实现的话可以仿照论文里的实现：https://godbolt.org/z/1heYYvW5K （这里的 clang trunk 编不过，我之后找时间看看）

具体做法可以参考 asio::string 的实现，比如说：

namespace async_simple::coro {
#if __cpp_lib_generator > 202207L
using std::generator;
#else
// ... implementations
#endif
}

---

感兴趣的话可以看看 folly 里的 AsyncGenerator，那个相对来说和异步的场景更贴合些。

[4kangjc]

因为 Generator 已经进入 C++标准了：https://github.com/cplusplus/papers/issues/1151，https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2502r2.pdf。所以要实现的话可以仿照论文里的实现：https://godbolt.org/z/1heYYvW5K （这里的 clang trunk 编不过，我之后找时间看看）

具体做法可以参考 asio::string 的实现，比如说：

namespace async_simple::coro {
#if __cpp_lib_generator > 202207L
using std::generator;
#else
// ... implementations
#endif
}

---

感兴趣的话可以看看 folly 里的 AsyncGenerator，那个相对来说和异步的场景更贴合些。

好，我试试

[4kangjc]

Hmm, 差个递归和Allocator

[4kangjc]

https://godbolt.org/z/1heYYvW5K

和 https://en.cppreference.com/w/cpp/header/generator 里的有点不同

[4kangjc]

相比于co_yield std::ranges::elements_of(might_throw());的递归方式，我觉得co_await might_throw()可能更简便些
std::generator不支持在body里co_await, 但实际上对称变换应该要允许的, 比如在generator里co_await lazy什么的

[ChuanqiXu9]

https://godbolt.org/z/1heYYvW5K

和 https://en.cppreference.com/w/cpp/header/generator 里的有点不同

我还没细看，主要哪里不同？

---

std generator 其实比起协程库更贴近于 Range 库，为了和 Range 的互操作性折腾了很多。虽然搞一个和 std generator 语义不同的 generator 也不是不行，但感觉有点奇怪。我的想法是 generator 的设计和实现都尽量把标准的搬过来就行，之后在 AsyncGenerator 里再做其他的事情。

因为本质上 generator （一般认为）是个同步组件，async_simple 更多是希望提供一些方便的异步组件，所以这里是有些差别的。

[4kangjc]

我看cppref 里 generator 里有一个
unique_ptr<stack<coroutine_handle<>>> active_;
godbolt里好像是在Promise里有个

struct _Nest_info {
            exception_ptr _Except;
            coroutine_handle<_Gen_promise_base> _Parent;
            coroutine_handle<_Gen_promise_base> _Root;
};

这两个目的应该都是为了优化Generator的递归, 实现应该不太同, 我还没细看, 我再看看

嗯好的 我之后再去看看folly的AsyncGenerator

[ChuanqiXu9]

clang找不到::operator delete[](void*, size_t)这个函数

可以自己hack一个

#if conditions
namespace std {
   ...
}
#endif

[4kangjc]

文档我慢慢加吧,可能会写得很慢

[ChuanqiXu9]

文档我慢慢加吧,可能会写得很慢

这个没有关系，那现在这个 PR 就不要求文档了。文档我也可以补下。

[4kangjc]

文档我慢慢加吧,可能会写得很慢

这个没有关系，那现在这个 PR 就不要求文档了。文档我也可以补下。

OK 好的 Lazy需要Allocator支持吗, 这个Allocator可以共享的, 我打算把promise_allocator另起一个文件, 只要让Promise继承它就行, 看看其他coroutine类型是否需要Allocator的支持

[ChuanqiXu9]

文档我慢慢加吧,可能会写得很慢

这个没有关系，那现在这个 PR 就不要求文档了。文档我也可以补下。

OK 好的 Lazy需要Allocator支持吗, 这个Allocator可以共享的, 我打算把promise_allocator另起一个文件, 只要让Promise继承它就行, 看看其他coroutine类型是否需要Allocator的支持

暂时先不用吧，加接口的事可以谨慎些。Coroutine 的语言设计里 Allocator 的位置挺奇怪，就挺不好用的，可以先放放。

[4kangjc]

文档我慢慢加吧,可能会写得很慢

这个没有关系，那现在这个 PR 就不要求文档了。文档我也可以补下。

OK 好的 Lazy需要Allocator支持吗, 这个Allocator可以共享的, 我打算把promise_allocator另起一个文件, 只要让Promise继承它就行, 看看其他coroutine类型是否需要Allocator的支持

暂时先不用吧，加接口的事可以谨慎些。Coroutine 的语言设计里 Allocator 的位置挺奇怪，就挺不好用的，可以先放放。

恩好

[ChuanqiXu9]

这个对应的是什么warning 呢？

[ChuanqiXu9]

这个 warning 在哪里出现的呢，看着不太对

[ChuanqiXu9]

这个 Wno 选项可以消掉吗？我感觉剩下的主要问题就是这个了

[ChuanqiXu9]

LGTM