[clang] [llvm] [Clang][Coroutines] Introducing the `[[clang::coro_inplace_task]]` attribute (PR #94693)

[Yuxuan Chen via llvm-commits]

yuxuanchen1997 wrote:

> What I thought is, to touch the code that generates the CallExpr specially instead of marking a CallExpr as special after that. The later generally looks not good to me.

The recursive structure in `EmitCallExpr` makes it hard to do this. There are just too many ways you can emit a CallExpr via `EmitCallExpr`. 

> For the later question, I roughly remember we can make it in several functions emitting CallExpr in CGExpr.cpp and CGExprCXX.cpp.

As far as I can tell, it's just the `CallOrInvoke` out parameter. What I have done was to just apply it all the way to the top level `EmitCallExpr`?

> Also we should try to avoid touch so many CodeGen* files if possible. It looks scary at first and not easy to maintain.

It is a little scary to do this at first, and there are cases like Pseudo destructors that don't end up being a Call or Invoke instruction. I still think this is easier to maintain than having `EmitCall` somehow know the context that this is a coroutine we can elide and do the marking there. 

>  It may be possible either due to new operator co_await overloads 

This we can check in the FE if the operator co_await we found was a member of the attributed type? If the search resulted in a nonmember operator we don't do the optimization?

> or due to the other await_transform didn't handle third party coroutine types well. 

Indeed. The general assumption is that if you do something in the await_transform to break the promise to the compiler, it should be obvious to the developer. 

> So may be, if possible, I feel better if we can add the attribute to awaiters.

That's also an option. The main conflict there being: 

https://github.com/llvm/llvm-project/pull/94693