Page MenuHomePhabricator
Feed Advanced Search

Mar 29 2020

junparser closed D76913: [Coroutines 2/2] Improve symmetric control transfer feature .
Mar 29 2020, 7:16 PM · Restricted Project
junparser closed D76911: [Coroutines 1/2] Improve symmetric control transfer feature .
Mar 29 2020, 7:16 PM · Restricted Project

Mar 28 2020

junparser added inline comments to D76913: [Coroutines 2/2] Improve symmetric control transfer feature .
Mar 28 2020, 8:24 PM · Restricted Project

Mar 27 2020

junparser set the repository for D76913: [Coroutines 2/2] Improve symmetric control transfer feature to rG LLVM Github Monorepo.
Mar 27 2020, 3:44 AM · Restricted Project
junparser updated the diff for D76913: [Coroutines 2/2] Improve symmetric control transfer feature .

minor update

Mar 27 2020, 3:44 AM · Restricted Project
junparser updated the summary of D76913: [Coroutines 2/2] Improve symmetric control transfer feature .
Mar 27 2020, 3:10 AM · Restricted Project
junparser created D76913: [Coroutines 2/2] Improve symmetric control transfer feature .
Mar 27 2020, 3:10 AM · Restricted Project
junparser updated the summary of D76911: [Coroutines 1/2] Improve symmetric control transfer feature .
Mar 27 2020, 3:10 AM · Restricted Project
junparser created D76911: [Coroutines 1/2] Improve symmetric control transfer feature .
Mar 27 2020, 3:10 AM · Restricted Project

Mar 23 2020

junparser committed rGa44de12ab219: [Coroutines] Also check lifetime intrinsic for local variable when build… (authored by junparser).
[Coroutines] Also check lifetime intrinsic for local variable when build…
Mar 23 2020, 10:50 PM
junparser committed rGd0f4af8f3088: [Coroutines] Insert lifetime intrinsics even O0 is used (authored by junparser).
[Coroutines] Insert lifetime intrinsics even O0 is used
Mar 23 2020, 10:50 PM
junparser closed D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.
Mar 23 2020, 10:50 PM · Restricted Project
junparser closed D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.
Mar 23 2020, 10:50 PM · Restricted Project
junparser updated the diff for D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.

update testcase.

Mar 23 2020, 10:49 PM · Restricted Project
junparser added inline comments to D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.
Mar 23 2020, 9:45 PM · Restricted Project
junparser added a comment to D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.

hi, @leonardchan, It seems that you disabled lifetime insertion at https://reviews.llvm.org/D63153. Is there any other reason to disable it beyond fix testcases? Also, could you please review this? we need lifetime check to prevent potential ‘use-after-free’ issue described at https://reviews.llvm.org/D75664

The main reason was just for the test fixes and parity with the legacy PM which didn't seem to include these intrinsics at O0. Beyond that, there was no real technical reason for disabling it.

LGTM in regards to adding them if LangOpts.Coroutines is set, but do make sure everyone else's comments are addressed.

Mar 23 2020, 7:04 PM · Restricted Project
junparser added a comment to D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.

hi, @leonardchan, It seems that you disabled lifetime insertion at https://reviews.llvm.org/D63153. Is there any other reason to disable it beyond fix testcases? Also, could you please review this? we need lifetime check to prevent potential ‘use-after-free’ issue described at https://reviews.llvm.org/D75664

Mar 23 2020, 3:48 AM · Restricted Project
junparser added a reviewer for D76119: [Coroutines] Insert lifetime intrinsics even O0 is used: leonardchan.
Mar 23 2020, 3:48 AM · Restricted Project
junparser added a watcher for debug-info: junparser.
Mar 23 2020, 3:15 AM

Mar 22 2020

junparser added a comment to D70555: [coroutines] Don't build promise init with no args.

LGTM

Mar 22 2020, 6:47 PM · Restricted Project

Mar 19 2020

junparser committed rG032251e34d17: [Coroutines] Fix PR45130 (authored by junparser).
[Coroutines] Fix PR45130
Mar 19 2020, 8:52 PM
junparser closed D76345: [Coroutines] Fix PR45130.
Mar 19 2020, 8:51 PM · Restricted Project
junparser updated the diff for D76345: [Coroutines] Fix PR45130.
Mar 19 2020, 8:50 PM · Restricted Project
junparser added a comment to D76345: [Coroutines] Fix PR45130.

Thanks for review! :)

Mar 19 2020, 8:20 PM · Restricted Project
junparser updated the diff for D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.

address the comments.

Mar 19 2020, 8:18 PM · Restricted Project
junparser abandoned D75977: [JumpThreading] Fix PR44611 .

see https://reviews.llvm.org/D76390

Mar 19 2020, 7:12 PM · Restricted Project

Mar 17 2020

junparser created D76345: [Coroutines] Fix PR45130.
Mar 17 2020, 11:13 PM · Restricted Project

Mar 16 2020

junparser added a comment to D75977: [JumpThreading] Fix PR44611 .

Sorry, the infinite recursion seems to come from EvaluateOnPredecessorEdge, a function that I recently added to support jump threading across two basic blocks. EvaluateOnPredecessorEdge does not have a guard against infinite recursion while its close cousin ComputeValueKnownInPredecessors does.

The best thing to do is to get rid of the code duplication I introduced, namely EvaluateOnPredecessorEdge, but for now we can detect infinite recursion by maintaining RecursionSet much like ComputeValueKnownInPredecessors. Alternatively, we could pass a recursion depth and stop recursion when we reach a certain limit. We have a limit on the number of LLVM IR statements we duplicate, so we could use that as a starting point.

Anyway, let me try to come up with something.

Mar 16 2020, 6:35 PM · Restricted Project

Mar 15 2020

junparser committed rG53c2e10fb8a6: [Coroutines] Do not evaluate InitListExpr of a co_return (authored by junparser).
[Coroutines] Do not evaluate InitListExpr of a co_return
Mar 15 2020, 9:44 PM
junparser closed D76118: [Coroutines] Do not evaluate InitListExpr of a co_return.
Mar 15 2020, 9:44 PM · Restricted Project
junparser updated the diff for D76118: [Coroutines] Do not evaluate InitListExpr of a co_return.

simplify the testcase

Mar 15 2020, 9:42 PM · Restricted Project
junparser added a comment to D76118: [Coroutines] Do not evaluate InitListExpr of a co_return.

@modocache thanks.

Mar 15 2020, 6:48 PM · Restricted Project
junparser added inline comments to D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.
Mar 15 2020, 6:48 PM · Restricted Project
junparser added a comment to D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.

@modocache Thanks !

Mar 15 2020, 6:15 PM · Restricted Project
junparser added inline comments to D75977: [JumpThreading] Fix PR44611 .
Mar 15 2020, 6:15 PM · Restricted Project
junparser added a comment to D75977: [JumpThreading] Fix PR44611 .

Hi junparser, your main change in JumpThreading.cpp looks good. Now, could you explain your change in removed-use.ll? To be honest, I haven't understood the original intent of the testcase. Thanks!

Mar 15 2020, 6:15 PM · Restricted Project

Mar 13 2020

junparser added a reviewer for D76119: [Coroutines] Insert lifetime intrinsics even O0 is used: chandlerc.
Mar 13 2020, 12:50 AM · Restricted Project
junparser created D76119: [Coroutines] Insert lifetime intrinsics even O0 is used.
Mar 13 2020, 12:50 AM · Restricted Project

Mar 12 2020

junparser created D76118: [Coroutines] Do not evaluate InitListExpr of a co_return.
Mar 12 2020, 11:25 PM · Restricted Project

Mar 11 2020

junparser added a reviewer for D75977: [JumpThreading] Fix PR44611 : wmi.
Mar 11 2020, 2:19 AM · Restricted Project
junparser created D75977: [JumpThreading] Fix PR44611 .
Mar 11 2020, 2:19 AM · Restricted Project

Mar 10 2020

junparser updated the diff for D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.

@wenlei @modocache would you please review the updated patch?
I make the update for :

  1. remove assertion since we use lifetime intrinsic as def
  2. support multiple lifetime intrinsic
  3. it invalidates one case in cppcoro (large number of synchronous completions doesn't result in stack-overflow) since we do not move local variables into frame now @lewissbaker would please udpate it?
Mar 10 2020, 3:46 AM · Restricted Project

Mar 9 2020

junparser added a comment to D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.

It seems that this patch also fix some workaround in folly, https://github.com/facebook/folly/blob/master/folly/Portability.h#L501, This is the same behavior as well as our coroutine library

Mar 9 2020, 3:43 AM · Restricted Project
junparser added a comment to D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.

It seems that this patch also fix some workaround in folly, https://github.com/facebook/folly/blob/master/folly/Portability.h#L501, This is the same behavior as well as our coroutine library

Mar 9 2020, 3:11 AM · Restricted Project

Mar 5 2020

junparser added a comment to D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.

Nice change, thanks @junparser! The improved dataflow analysis using lifetime instead of allocation point and the resulting shrink-wrapping style opt for alloca would definitely be beneficial.

For data race however, I'm not sure if I understand it correctly, could you elaborate (perhaps with a concrete example..) why this is compiler's fault?

For

auto await_suspend(std::experimental::coroutine_handle<> h) {
    auto& pr = h.promise();
    if (pr._ex) {
        // schedule to another thread
        pr._ex->schedule([&pr]() {
            pr._continuation.resume();
        });
    }
}

This case shows data race with inline, and does not when not inlined. It looks like both the current thread and schedule thread access some fields of std::function when I dig into the ir. I'm not sure whether this is caused by std::function constructor/destructor or move allocas to frame. I get such conclusion based on ir.

Mar 5 2020, 6:04 PM · Restricted Project
junparser added a comment to D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.

Nice change, thanks @junparser! The improved dataflow analysis using lifetime instead of allocation point and the resulting shrink-wrapping style opt for alloca would definitely be beneficial.

For data race however, I'm not sure if I understand it correctly, could you elaborate (perhaps with a concrete example..) why this is compiler's fault?

Mar 5 2020, 5:31 PM · Restricted Project
junparser created D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame.
Mar 5 2020, 12:03 AM · Restricted Project

Mar 4 2020

junparser committed rGb10deb9487e1: [Coroutines] Optimized coroutine elision based on reachability (authored by junparser).
[Coroutines] Optimized coroutine elision based on reachability
Mar 4 2020, 10:58 PM
junparser closed D75440: [Coroutines] Optimized coroutine elision based on reachability.
Mar 4 2020, 10:58 PM · Restricted Project
junparser updated the diff for D75440: [Coroutines] Optimized coroutine elision based on reachability.

update the patch as suggestion

Mar 4 2020, 10:58 PM · Restricted Project

Mar 3 2020

junparser added a comment to D75440: [Coroutines] Optimized coroutine elision based on reachability.

yep, I have tried the two samples, same behavior as clang6.

Phenomenal!! Thanks for checking. Please feel free to address the nit-pick comments only if you wish. I'll wait to accept until I better understand the rationale for checking the number of cases in a suspend switch statement, if that's alright.

Mar 3 2020, 5:52 PM · Restricted Project

Mar 2 2020

junparser added a comment to D75440: [Coroutines] Optimized coroutine elision based on reachability.

Thank you for this patch, I'll give it a proper review tonight. But in the meantime, I wonder if you've tried this with any of the sample programs for this bug report, https://bugs.llvm.org/show_bug.cgi?id=40656 ?

Mar 2 2020, 6:33 PM · Restricted Project
junparser created D75440: [Coroutines] Optimized coroutine elision based on reachability.
Mar 2 2020, 1:54 AM · Restricted Project

Mar 1 2020

junparser committed rG624dbfcc1b81: [Coroutines][New pass manager] Move CoroElide pass to right position (authored by junparser).
[Coroutines][New pass manager] Move CoroElide pass to right position
Mar 1 2020, 5:57 AM
junparser updated the diff for D75345: [Coroutines][new pass manager] Move CoroElide pass to right position.

Update clang testcase to avoid check-clang failure

Mar 1 2020, 5:51 AM · Restricted Project
junparser committed rG44d83671c59e: Revert "[Coroutines][new pass manager] Move CoroElide pass to right position" (authored by junparser).
Revert "[Coroutines][new pass manager] Move CoroElide pass to right position"
Mar 1 2020, 5:39 AM
junparser added a reverting change for rG4c0a133a412c: [Coroutines][new pass manager] Move CoroElide pass to right position: rG44d83671c59e: Revert "[Coroutines][new pass manager] Move CoroElide pass to right position".
Mar 1 2020, 5:39 AM
junparser committed rG4c0a133a412c: [Coroutines][new pass manager] Move CoroElide pass to right position (authored by junparser).
[Coroutines][new pass manager] Move CoroElide pass to right position
Mar 1 2020, 5:03 AM
junparser closed D75345: [Coroutines][new pass manager] Move CoroElide pass to right position.
Mar 1 2020, 5:03 AM · Restricted Project

Feb 28 2020

junparser added a comment to D75345: [Coroutines][new pass manager] Move CoroElide pass to right position.

Thanks for the patch, @junparser! Curious how did you notice this - was it causing performance regression for your workload?

Feb 28 2020, 8:07 PM · Restricted Project
junparser created D75345: [Coroutines][new pass manager] Move CoroElide pass to right position.
Feb 28 2020, 5:28 AM · Restricted Project

Feb 27 2020

junparser committed rG43c8307c6c4e: [Coroutines] CoroElide enhancement (authored by junparser).
[Coroutines] CoroElide enhancement
Feb 27 2020, 6:45 PM
junparser closed D71663: [Coroutines] CoroElide enhancement .
Feb 27 2020, 6:45 PM · Restricted Project
junparser updated the diff for D71663: [Coroutines] CoroElide enhancement .

Rebase and update the patch as suggestion.

Feb 27 2020, 6:44 PM · Restricted Project
junparser added a comment to D71663: [Coroutines] CoroElide enhancement .

Sorry this review took so long, and thank you for addressing the regression I introduced in D43242!

This patch no longer cleanly applies due to my changes in D71900, but I believe I was able to rebase it correctly in P8200. Based on that I think this looks like a great improvement, thank you!

Do you have commit access now, or would you like me to commit this (once you've updated it to apply cleanly) on your behalf?

Yes , thanks for review the patch.
And I have got the commit access, however, how do I push the patch? Any hint for first time checkin ? Thank you again.

@modocache Thanks, I have committed the patch.

Feb 27 2020, 6:44 PM · Restricted Project

Feb 26 2020

junparser added a comment to D71663: [Coroutines] CoroElide enhancement .

Sorry this review took so long, and thank you for addressing the regression I introduced in D43242!

This patch no longer cleanly applies due to my changes in D71900, but I believe I was able to rebase it correctly in P8200. Based on that I think this looks like a great improvement, thank you!

Do you have commit access now, or would you like me to commit this (once you've updated it to apply cleanly) on your behalf?

Feb 26 2020, 6:33 AM · Restricted Project

Jan 16 2020

junparser added a comment to D71663: [Coroutines] CoroElide enhancement .

gental ping~

Jan 16 2020, 6:24 PM · Restricted Project

Jan 5 2020

junparser added a comment to D71826: [Coroutines] Remove corresponding phi values when apply simplifyTerminatorLeadingToRet.

Done! Please excuse the wait. Have you considered getting commit access to LLVM? You won't have to wait on me in the future :) https://llvm.org/docs/DeveloperPolicy.html#new-contributors

Jan 5 2020, 5:49 PM · Restricted Project

Jan 4 2020

junparser added a comment to D71663: [Coroutines] CoroElide enhancement .

@modocache kindly ping~

Jan 4 2020, 2:56 AM · Restricted Project
junparser added a comment to D71903: [Coroutines][6/6] Clang schedules new passes.

I'm currently working on ensuring that CGSCC optimizations are rerun to optimize coroutine funclets -- the primary feedback I received on this and on D71899 -- but I just realized I didn't respond to one comment on this set of reviews, from @junparser:

There is another issue we should consider: clang is crashed when compile coroutine with -disable-llvm-passes and output an object file.

It's always been the case, since the coroutine intrinsics and passes were first added to LLVM, that attempting to codegen without first running coroutine passes would cause a crash during instruction selection. So clang -Xclang -disable-llvm-passes -c has always crashed Clang during LLVM ISel, as it does in this example that uses Clang 9.0.0 and the legacy pass manager: https://godbolt.org/z/Mj2R5G

Personally I'm of the opinion that this is less than ideal... I may be wrong, but I don't think there are very many other C++ features that *require* Clang to run LLVM passes (perhaps the always_inline attribute requires LLVM passes to be run for correctness? I'm not sure). So I would like to see this eventually addressed somehow.

Is it reasonable to run coroutine passes even -disable-llvm-passes is enabled?

My personal opinion is that this would not be reasonable. The option -disable-llvm-passes should, from my point of view, prevent any and all LLVM passes from being run. I also frequently make use of this option when debugging the LLVM IR being output for C++ coroutines code, so if -disable-llvm-passes didn't disable coroutines passes, I'd need another option that did (-disable-llvm-passes-no-really-even-coroutine-passes-them-too 😅).

All this being said, considering this behavior has existed in the legacy PM since day one, I think we should start a separate discussion on if/how to change that behavior. I'm working on an update for these patches to address funclet optimization, but the update will not change the fact that coroutine passes are not run when -disable-llvm-passes is specified. I think that's an orthogonal issue.

Jan 4 2020, 2:43 AM · Restricted Project

Dec 30 2019

junparser added a comment to D71899: [Coroutines][2/6] New pass manager: coro-split.

The devirt trigger here is to restart CGSCC pipeline to run coro-split again to split the coroutine function. There is no need to introduce devirt trigger in NewPM since we call coro-split pass manually.

Manually schedule the 2nd coro-split pass is only a workaround before we can trigger CGSCC passes on the split funclet like we did for legacy PM. It does the split without restarting CGSCC passes so it works, but it also leaves performance on the table because the split funclets won't go through many opt passes of CGSCC pipeline. Yes, I agree don't need to introduce devirt trigger with new PM, but that's because I think we can request CGSCC passes on split funclet via other mechanism like CGSCCUpdateResult, not just because 2nd coro-split pass is manually scheduled.

There are two issues here: 1) coro-split needs run at least twice, we do not need CGSCC pipeline at pre-split stage which coro-split pass just works as a function pass 2) request CGSCC passes on split funclet after 2nd running of coro-split, and coroutine optimization such as coro-elide pass also depends on these optimization.
Manually schedule coro-split twice is a workaround for 1), as for 2) the current pipeline of coroutine in this patch set need be changed.

Dec 30 2019, 10:52 PM · Restricted Project
junparser added a comment to D71899: [Coroutines][2/6] New pass manager: coro-split.

My understanding is devirt trigger is only a trick used with Legacy PM to run optimizations on coroutine funclets after coro-split. With NewPM's CGSCCUpdateResult infra, can we communicate that change and request passes directly with ModuleToPostOrderCGSCCPassAdaptor, without artificially introducing the indirect call and devirt?

The devirt trigger here is to restart CGSCC pipeline to run coro-split again to split the coroutine function. There is no need to introduce devirt trigger in NewPM since we call coro-split pass manually.

Dec 30 2019, 7:55 PM · Restricted Project

Dec 29 2019

junparser updated the diff for D71826: [Coroutines] Remove corresponding phi values when apply simplifyTerminatorLeadingToRet.

update the testcase, and @modocache can you commit this patch? thanks.

Dec 29 2019, 6:46 PM · Restricted Project
junparser added a comment to D71903: [Coroutines][6/6] Clang schedules new passes.

There is another issue we should consider: clang is crashed when compile coroutine with -disable-llvm-passes and output an object file.
Is it reasonable to run coroutine passes even -disable-llvm-passes is enabled?

Dec 29 2019, 6:10 PM · Restricted Project
junparser added a comment to D71826: [Coroutines] Remove corresponding phi values when apply simplifyTerminatorLeadingToRet.

Sorry for the wait here, @junparser! I wanted to send my own patches out before looking at this one 😛

This is really nice, thanks for the change! As per your test plan, I confirmed that with this patch, cppcoro issue https://github.com/lewissbaker/cppcoro/issues/109 no longer reproduces for me. The jump threading issue you describe must have been responsible for Clang hanging indefinitely when compiling that test file.

I had one nitpick related to your test, please address it or not at your own discretion. This patch LGTM.

Dec 29 2019, 6:01 PM · Restricted Project
junparser added a comment to D71663: [Coroutines] CoroElide enhancement .

@modocache kindly ping~

Dec 29 2019, 6:01 PM · Restricted Project

Dec 26 2019

junparser added inline comments to D71903: [Coroutines][6/6] Clang schedules new passes.
Dec 26 2019, 9:40 PM · Restricted Project
junparser added a comment to D71826: [Coroutines] Remove corresponding phi values when apply simplifyTerminatorLeadingToRet.

@modocache kindly ping~

Dec 26 2019, 3:37 AM · Restricted Project

Dec 22 2019

junparser added a comment to D71663: [Coroutines] CoroElide enhancement .

kindly ping~

Dec 22 2019, 11:20 PM · Restricted Project
junparser created D71826: [Coroutines] Remove corresponding phi values when apply simplifyTerminatorLeadingToRet.
Dec 22 2019, 11:20 PM · Restricted Project

Dec 18 2019

junparser updated the summary of D71663: [Coroutines] CoroElide enhancement .
Dec 18 2019, 7:11 AM · Restricted Project
junparser created D71663: [Coroutines] CoroElide enhancement .
Dec 18 2019, 7:11 AM · Restricted Project

Nov 28 2019

junparser added a comment to D70579: [coroutines][PR41909] Generalize fix from D62550.

This also fix same ice when build cppcoro with current trunk. FYI

Nov 28 2019, 5:48 PM · Restricted Project

Nov 22 2019

junparser added a comment to D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves.

LGTM, thanks! Please let me know if you'd like me to commit this change.

Nov 22 2019, 2:46 AM · Restricted Project

Nov 21 2019

junparser added a comment to D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves.

Sorry for the slow response here, @junparser!

The test case you came up with here is great! I can see the issue is that ScopeInfo->CoroutineParameterMoves are built up when Clang parses the first co_await a, but are not cleared when lookupPromiseType results in an error. As a result, when Clang hits the second co_await a, it's in a state that the current code didn't anticipate. Your test case does a great job demonstrating this. Your fix for the problem also looks good to me! My only suggestion is to make the test case just a little clearer, as I'll explain...

(Also, in the future could you please upload your patches with full context? You can read https://llvm.org/docs/Phabricator.html for more details. I think the section explaining the web interface might be relevant to you, where it suggests git show HEAD -U999999 > mypatch.patch. The reason I ask is because on Phabricator I can see what lines you're proposing should be added, but not the surrounding source lines, which made this more difficult to review.)

Nov 21 2019, 7:39 PM · Restricted Project
junparser updated the diff for D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves.

update as @modocache's suggestion

Nov 21 2019, 7:30 PM · Restricted Project

Oct 25 2019

junparser updated subscribers of D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves.

Despite generally knowing about coroutines and generally knowing about Clang, I actually don't know the Clang coroutine code and can't review this properly.

Oct 25 2019, 9:02 AM · Restricted Project

Oct 24 2019

junparser added a reviewer for D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves: rjmccall.
Oct 24 2019, 11:32 AM · Restricted Project

Oct 21 2019

junparser added a comment to D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves.

gental ping~ @modocache @GorNishanov

Oct 21 2019, 8:51 AM · Restricted Project

Oct 16 2019

junparser created D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves.
Oct 16 2019, 12:59 AM · Restricted Project