================
@@ -7575,15 +7577,27 @@ static void
visitLifetimeBoundArguments(IndirectLocalPath &Path, Expr *Call,
Path.pop_back();
};
- if (ObjectArg && implicitObjectParamIsLifetimeBound(Callee))
- VisitLifetimeBoundArg(Callee, ObjectArg);
-
bool CheckCoroCall = false;
if (const auto *RD = Callee->getReturnType()->getAsRecordDecl()) {
CheckCoroCall = RD->hasAttr<CoroLifetimeBoundAttr>() &&
RD->hasAttr<CoroReturnTypeAttr>() &&
!Callee->hasAttr<CoroDisableLifetimeBoundAttr>();
}
+
+ if (ObjectArg) {
+ bool CheckCoroObjArg = CheckCoroCall;
+ // Ignore `__promise.get_return_object()` as it is not lifetimebound.
+ if (CheckCoroObjArg && Callee->getDeclName().isIdentifier() &&
+ Callee->getName() == "get_return_object")
+ CheckCoroObjArg = false;
+ // Coroutine lambda objects with empty capture list are not lifetimebound.
+ if (auto *LE = dyn_cast<LambdaExpr>(ObjectArg->IgnoreImplicit());
+ LE && LE->captures().empty())
+ CheckCoroObjArg = false;
----------------
ChuanqiXu9 wrote:
> > I didn't get the logic here. Why it is not good to warn the undefined
> > things?
>
> Sorry, I wasn't clear here. I meant that if it is UB, we should warn for
> those cases too and remove this code path.
>
> > I feel it is literally undefined. Since the spec doesn't say a lot about
> > resumption/suspension about coroutines. Also the description of
> > http://eel.is/c++draft/dcl.fct.def.coroutine#note-3 is vague too. It says
> > it is likely to be an undefined behavior.
>
> Yeah, this looks suspicious. At the same time, it's very similar to `delete
> this`, which (IIUC) is not UB as long as people are careful to not access
> `this` after doing it.
>
> I have actually asked the CWG, but got no reply so far.
Got it. Then it might not be a UB (we didn't access `this` in the empty lambda)
if we're comparing this case. While I don't object wait for response from CWG,
I feel we can continue here. On the one hand, we're talking about the behaviors
with an extension (`[[clang::coro_lifetime_bound]]`) which can be visited as a
dialect. On the other hand, it is somewhat not user friendly to emit warnings
in such cases.
https://github.com/llvm/llvm-project/pull/77066
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
