- User Since
- Feb 16 2014, 1:10 AM (291 w, 4 d)
Fri, Sep 13
I work on a C++17 codebase with coroutines enabled, but yes
just formatting the codebase as if it were C++20 seems fine. Thanks!
Oh, thank you! Yes, I had been meaning to abandon this and my other patch.
Wed, Sep 11
Aug 14 2019
Thanks for looking into this, @GorNishanov! LGTM aside from a tiny nit-pick.
Aug 13 2019
Aug 11 2019
Aug 9 2019
Thanks for the review, @vsk! Sorry it took me so long to update this diff.
Aug 8 2019
Thanks for the review, @Quuxplusone! I addressed your test comments, but the 'co_yield' test is something I think I'll need to deal with separately.
Aug 7 2019
Friendly ping! @sammccall is this what you had in mind?
Aug 5 2019
Thanks for the reviews, @sammccall, @Quuxplusone, and @MyDeveloperDay. I added C++14 and C++17 options. In an earlier comment I mentioned splitting this work up into a series of commits, but it ended up being a smaller set of changes than I thought, so I'll just update this diff with all of the changes. What do you all think?
Jul 26 2019
Sure thing! Just to be clear: this test doesn't fail, it passes. My intention was to commit this, then commit a patch that improved the indentation behavior, which would also include a change to the test that demonstrated the new behavior. But, as per your suggestion, I'll wait for the fix before committing this. Thanks!
Jul 24 2019
It sounds like currently they're very different, and you're proposing to make them basically the same. I think that's a good thing.
Jul 23 2019
LGTM, but I don't actively work in this codebase so I really can't say. I'll wait to hear from some other more active clang-format reviewers.
Friendly ping! I'm wondering, from the clang-format maintainers' point of view, whether a diff like this and https://reviews.llvm.org/D65044 make sense to add? I do think that it is useful for users to specify whether they wish to use C++11 or C++20 constructs, but I'm not an expert.
Jul 22 2019
Noted, I'll try to work on this issue in early August, at the latest. In the meantime feel free to claim that bug report and submit a patch. Unfortunately unless someone develops a patch and immediately requests it be merged into the LLVM 9.0.0 release branch, I don't think it'll be in 9.0.0.
Jul 20 2019
Jul 2 2019
I'm not sure this is correct.
Jun 21 2019
Excellent, thank you! One of the comments on this diff mentioned using llvm-dwarfdump --verify to test whether the debug info generated by this option is valid. Have you tried doing so? Could you add a test case to this patch?
Jun 18 2019
Hello! Would anyone be willing to review this patch? Is there anything that could be tweaked, maybe putting this behavior behind an option, that would make the change more amenable to any reviewers?
Jun 15 2019
Jun 2 2019
Great, thanks for the review!
May 28 2019
@rsmith, what do you think of the patch as-is?
May 21 2019
Hmm... alright, I'm not really sure how I could implement a test that fails without this, but I added a check in the FindExistingResult destructor.
May 16 2019
May 15 2019
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!)
May 13 2019
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.