================
@@ -15845,8 +15845,10 @@ void Sema::CheckCoroutineWrapper(FunctionDecl *FD) {
   RecordDecl *RD = FD->getReturnType()->getAsRecordDecl();
   if (!RD || !RD->getUnderlyingDecl()->hasAttr<CoroReturnTypeAttr>())
     return;
-  // Allow `get_return_object()`.
-  if (FD->getDeclName().isIdentifier() &&
+  // Allow some_promise_type::get_return_object().
+  // Since we are still in the promise definition, we can only do this
+  // heuristically as the promise may not be yet associated to a coroutine.
+  if (isa<CXXMethodDecl>(FD) && FD->getDeclName().isIdentifier() &&
       FD->getName().equals("get_return_object") && FD->param_empty())
     return;
----------------
ilya-biryukov wrote:

> I do not think that would work either. For example, consider TUs with only 
> promise definitions and no coroutine definitions. These attr would not be 
> available even in the end of TU.

But in that case we shouldn't see any `coro_return_type` annotations either and 
there will be no pending actions? I don't see why this approach won't work.

I am worried about breaking the ODR rules, though. @ChuanqiXu9 is it fine to 
add attributes to existing functions conditioned on how they are used rather 
than how they are defined?

Imagine two modules:
- one only defines the promise type, but never actually uses it as a coroutine, 
so we don't happen to get those attributes.
- another one imports the module from the previous step and attributes get 
added.

We can now easily get object files that have both definitions of those 
functions with and without the attributes (by importing either one of the 
other). I am not sure if there are some potential failures lurking in if we do 
that, e.g. could ODR hash checks for importing both as submodules will fail?

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

Reply via email to