[PATCH] D26038: [coroutines] Sema: Allow co_return all by itself.

[Eric Fiselier via Phabricator via llvm-commits]

EricWF added a comment.

In https://reviews.llvm.org/D26038#614584, @GorNishanov wrote:

> In https://reviews.llvm.org/D26038#613723, @EricWF wrote:
>
> > @GorNishanov Ping. Can you provide some clarity on this?
>
>
> Starting from P0057R2, wording stated: 8.4.4/1: A function is a coroutine if it contains a coroutine-return-statement (6.6.3.1), an await-expression (5.3.8), a yield-expression (5.21), or a range-based for (6.5.4) with co_await.
>
> Before the Big Kona Keyword Rename of 2015, you had to have 'await' or 'yield' for a function to a be a coroutine. Now, since, co_return is only usable in coroutines, have a co_return also triggers the coroutine processing.
>
>   task<int> f() {
>     Do something (no await here) 
>     #if 0 // not yet implemented
>        something with await
>     #endif
>     co_return 42;
>   }
>  
>
>
> This is not the reason to have co_return, but, once we have it, I think using it as one of the indicators that a function is a coroutine is a reasonable approach.


Clang already treats functions with only co_return as coroutines, the diagnostic is a warning not an error.  Although IMHO Clang should emit a warning in this case. Obviously it's a false positive in your above example; but in general writing coroutines w/o `co_return` or `co_await` is a misuse of coroutines.


https://reviews.llvm.org/D26038