[cfe-dev] Is it the time to mark coroutine status as green in cxx_status page?

[chuanqi.xcq via cfe-dev]

I think the current situation might be the latter one. Now the coroutine is used heavily and broadly in production. 
And we didn't see the question for the implementation of semantics. Most of the similar problems come from langugae side.
e.g., why a promise_type couldn't define return_void and return_value and so on.

So I think it is sufficent to say "we have some support but incomplete support".

Thanks,
Chuanqi


------------------------------------------------------------------
From:Richard Smith <richard at metafoo.co.uk>
Send Time:2021年12月15日(星期三) 11:16
To:chuanqi.xcq <yedeng.yd at linux.alibaba.com>
Cc:lewissbaker <lewissbaker at gmail.com>; clang developer list <cfe-dev at lists.llvm.org>
Subject:Re: [cfe-dev] Is it the time to mark coroutine status as green in cxx_status page?

On Tue, 14 Dec 2021 at 19:01, chuanqi.xcq via cfe-dev <cfe-dev at lists.llvm.org> wrote:
Hi Richard,

   Thank you for telling the whole process to mark a language feature done. Although it seems hard, I know how to make it now.

   And a bad news is that I defined the feature test macro `__cpp_impl_coroutine` previously when I move the coroutine components out of experimental namespace... 
The intention why I introduce this is that I want to make libcxx known if the compiler is new enough to search coroutine components in std namespace.
Do you think we should undefine the macro in another patch? 

If we're not confident that we're done with the implementation, then yes, we should urgently stop defining the macro to the value specified in the standard. If you want to define it as, say, 1 in the interim, to indicate that we have some support but incomplete support, that's probably OK.
Thanks,
Chuanqi

------------------------------------------------------------------
From:Richard Smith <richard at metafoo.co.uk>
Send Time:2021年12月15日(星期三) 10:45
To:chuanqi.xcq <yedeng.yd at linux.alibaba.com>
Cc:clang developer list <cfe-dev at lists.llvm.org>; lewissbaker <lewissbaker at gmail.com>
Subject:Re: [cfe-dev] Is it the time to mark coroutine status as green in cxx_status page?

This feature is marked as partial, in part, because we don't know what's missing. We implemented against a moving target (the C++ Coroutines TS and evolving work towards the final standard feature), and there's no guarantee we didn't miss changes along the way. So, the major piece of work we're missing here is: someone needs to go through the sections on coroutines in the C++ standard, and make sure that all the work listed there has been implemented and is tested. Someone should also go through all the open bugs on coroutines and see which ones are sufficiently important that we should not claim conformance until we address them. That'll either result in a todo list of the remaining items, or a conclusion that we are in fact done.

Once we're done, we'll need to update our feature test macro to match; then we can mark it as done on the status page.
On Mon, 13 Dec 2021 at 18:55, chuanqi.xcq via cfe-dev <cfe-dev at lists.llvm.org> wrote:
Hi,

   I noticed that the status of coroutine in cxx_status page is partial previously: https://clang.llvm.org/cxx_status.html.
   This looks weird to me since coroutine is used broadly and stably in practice and I want to mark it as green. So I tried
to move coroutine out of the experimental namespace before and implement the semantics of throwing unhandled_exception()
suggested by Lewis.
   So I sent https://reviews.llvm.org/D115692 to mark coroutine as done. I want to ask if there is any blocking issue to do this?
I would love to try to fix any inconsistency.

Thanks,
Chuanqi_______________________________________________
 cfe-dev mailing list
cfe-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
 cfe-dev mailing list
cfe-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211215/48b200dc/attachment-0001.html>