[PATCH] D62550: [coroutines][PR41909] Don't build dependent coroutine statements for generic lambda

Brian Gesiak via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Jun 15 13:10:08 PDT 2019


modocache added inline comments.


================
Comment at: cfe/trunk/lib/Sema/TreeTransform.h:7173
+    auto *MD = dyn_cast_or_null<CXXMethodDecl>(FD);
+    if (!MD || !MD->getParent()->isGenericLambda()) {
+      assert(!Promise->getType()->isDependentType() &&
----------------
rsmith wrote:
> This assert doesn't seem correct to me; there's no reason to assume we have a generic lambda here. (A non-generic lambda inside a generic lambda, whose parameter types are dependent on the generic lambda's parameters, would hit exactly the same issue, for instance.)
> 
> Generally we should write the template instantiation code so it could be used to substitute into the definition of a function template to produce another function template, even if we happen to never call it that way right now (though deduction guide processing gets pretty close). The right thing to do here is to either substitute into the representation we already formed (building a dependent representation if it's still dependent and a non-dependent representation otherwise) or to rebuild the coroutine body from scratch (again, creating a dependent representation if the result is still dependent).
Sorry I missed this! Indeed you're right, the check here is weak, and even with this patch the following coroutines code crashes in the same way: https://godbolt.org/z/ixLpCq

I'll send a follow-up patch that attempts to implement one of the approaches you describe. Thanks for the guidance!


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62550/new/

https://reviews.llvm.org/D62550





More information about the cfe-commits mailing list