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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
