- User Since
- Feb 16 2014, 1:10 AM (274 w, 9 h)
Thu, May 16
Wed, May 15
Oops, sent the patch from the wrong repository.
Thanks for the help, @rsmith! Your suggestions were spot-on. (It took me a little while to figure out why, even using the LazyDeclPtr directly, I was still triggering deserialization. It turns out dump() causes deserialization too -- whoops!)
Mon, May 13
Thanks @rsmith for the guidance here! I appreciate it very much. One snag I ran into after following your suggestion, though, is that when I modify ASTDeclReader::findExisting to return Sema's existing implicit std namespace, I run into an assertion later on, when the decl chain is being marked as incomplete. That is, the following patch (debug output included):
Apr 2 2019
Mar 26 2019
Apologies, I forgot to include in the commit message:
Committed in rL357010. Apologies, I forgot to include the differential revision in the commit message so this diff wasn't closed automatically as a result. I'll comment on rL357010 with the missing information.
Mar 25 2019
Right, that makes sense @jordan_rose. I'll submit this to swift-llvm, then.
Remove unneeded change to test identifier 'xx'.
Mar 24 2019
Thank you for the review!
Mar 22 2019
Sorry for the late response, I'm looking now. Should I revert this for now?
I'm pushing a revert. Sorry for the trouble!
Mar 18 2019
Friendly ping, @sylvestre.ledru! I'm also experiencing this build error. It looks like other diffs have been submitted to fix this, such as https://reviews.llvm.org/D59162, but it was abandoned in favor of this patch. It'd be great if you could commit this one.
Mar 15 2019
Great, thanks for the reviews, everyone!
I realize this isn't the correct solution, but would any would-be reviewers like to comment on the problem? Whether it's here or on the Bugzilla report https://bugs.llvm.org/show_bug.cgi?id=39287, as a newcomer to Clang modules I could use some help understanding whether this sort of behavior is expected, or if there are known workarounds. Any and all comments appreciated!
Mar 14 2019
OK, I've responded to all your review comments -- thank you! Please give this another look when you get a chance. I would like to emit note diagnostics pointing to the catch blocks, but I've left that as a FIXME for now.
Remove unused function parameter.
Thank you for the reviews! This revision fixes the nested try/catch behavior. I still need to modify this such that semantic analysis continues for the rest of the function body.
Mar 11 2019
Thanks @GorNishanov! I moved the call into splitCoroutine. I'll land this now.
Oops! Thanks for pointing that out @davide -- I had meant to pass them through to the DeleteDeadBlocks but forgot. Should be good now!
Mar 8 2019
Friendly ping! I thought this might be easier to review if I split it up from https://reviews.llvm.org/D59068, which fixes a bug in coroutines and has already been accepted. This diff is an NFC but is necessary to land the bug fix.
Mar 7 2019
Thanks for the review!
Add test case for executing a lambda using co_yield within a catch block.
Mar 6 2019
Mar 4 2019
Looks good, thanks for adding a driver option for this!
Mar 1 2019
Jan 31 2019
Thanks for the reviews!
Friendly ping! Is there anything I can do to improve this patch? I think it's a clear improvement of the diagnostic, with a test case to boot!
Jan 30 2019
Thanks, @cpplearner! You're absolutely right. I got confused because I didn't realize that the method FunctionProtoType::getUnqualifiedType was being used from within Sema::FunctionParamTypesAreEqual, not QualType::getUnqualifiedType. I modified my patch to use ASTContext::hasSameUnqualifiedType instead.
Jan 21 2019
Jan 10 2019
Great, thanks for the review!
Jan 9 2019
Remove obsoleted code I accidentally included.
Thanks for the offline review @GorNishanov! This revision allows constexpr usages of __builtin_coro_frame_max_size.
Jan 6 2019
Thank you for the review!
Jan 3 2019
Jan 2 2019
Dec 21 2018
Excellent progress! Thanks for working on this.
Dec 19 2018
Dec 18 2018
Dec 17 2018
Dec 12 2018
Dec 11 2018
LGTM! As it happens I was reading this code the other day and wondering why it wasn't able to eliminate a suspend point I'd been looking at. I'll try it again and see if this new behavior is able to eliminate -- thanks!
Dec 10 2018
Sorry for the wait! Mostly nits, but also I think the while condition might be inverted? It seems like, as is, it would never execute the body of the loop...?