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

[Chuanqi Xu via llvm-commits]

ChuanqiXu9 wrote:

> > As I said, I prefer to do this in Parser or Sema if possible.
> 
> Most of the logic is already in Sema in this version. This piece is at the very end of funnel in FE. Hence I am asking about what mechanisms we can use to obtain the `CallInst` or `InvokeInst` based on a known `CallExpr` during CodeGen.

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. 

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

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

> As for the name, what do you think about [[clang::coro_strict_elide]]?

For the current one, I prefer a more direct name `coro_elide_after_await`. It still looks confusing to understand what is `strict` for users.

> 
> > BTW, I am thinking about the safety issue. For example, one has coroutine type with the attribute, and the other has a coroutine type with this attribute too. Then how can we be sure the behavior is expected/well defined when a third user co_await a coroutine type within another one?
> 
> When you co_await a prvalue of Task2 from within Task1. The only way handles gets passed from Task1 to Task2 (or vice versa) is through one of its customization points (await_suspend, await_transform). The library needs to ensure proper use of the handles. There shouldn't be anything the third person cannot do because the Task types should not hand control of the handle to the users.

What I am concerning is the potential misuses. e.g., we have a class marked with this attribute. But in the user's code, for whatever reasons (maybe introducing other coroutine types), the semantics of `co_awaiting` our class changes. It may be possible either due to new `operator co_await overloads` or due to the other `await_transform` didn't handle third party coroutine types well. After all, I think the conflict point is, it is the `awaiter` controls the behavior of `co_await` expression not the so-called coroutine types. So may be, if possible, I feel better if we can add the attribute to awaiters.

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