This is an archive of the discontinued LLVM Phabricator instance.

[coroutines] Fix diagnostics depending on the first coroutine statement.
ClosedPublic

Authored by EricWF on Mar 8 2017, 11:59 PM.

Details

Summary

Some coroutine diagnostics need to point to the location of the first coroutine keyword in the function, like when diagnosing a return inside a coroutine. Previously we did this by storing each *valid* coroutine statement in a list and select the first one to use in diagnostics. However if every coroutine statement is invalid we would have no location to point to.

This patch fixes the storage of the first coroutine statement location, ensuring that it gets stored even when the resulting AST node would be invalid.
This patch also removes the CoroutineStmts list in FunctionScopeInfo because it was unused.

Diff Detail

Event Timeline

EricWF created this revision.Mar 8 2017, 11:59 PM
This revision is now accepted and ready to land.Mar 9 2017, 6:48 AM
GorNishanov requested changes to this revision.Mar 9 2017, 6:57 PM

One thought I had with respect to removing array of statements: We need to check during Sema that await_ready returns a type contextually convertible to bool and await_suspend returns either void or bool. If we have this array, I can quickly run through it and verify that all await expressions have expected types during CheckCoroutine body. With the yield/await expression vector removed, I am not sure where would be an appropriate spot to check for that.

This revision now requires changes to proceed.Mar 9 2017, 6:57 PM
EricWF added a comment.Mar 9 2017, 7:11 PM

Good to know. I'll update this tomorrow.

Good to know. I'll update this tomorrow.

Well, that is just the thought. Possibly we can check for the types of await_ready and await_suspend in BuildResolvedCoawaitExpr. Then, we don't have to keep the vector of await/yield-expressions.

Good to know. I'll update this tomorrow.

Well, that is just the thought. Possibly we can check for the types of await_ready and await_suspend in BuildResolvedCoawaitExpr. Then, we don't have to keep the vector of await/yield-expressions.

I guess it depends on when we want the diagnostics to be issued. And I think emitting them as they are built makes the most sense. If we attempt to issue the diagnostics at the end of the body it may be too late.

Do you still want me to put the vector back in now or when the need actually arises?

GorNishanov accepted this revision.Mar 10 2017, 5:41 PM

Alright, then. LGTM once more!

This revision is now accepted and ready to land.Mar 10 2017, 5:41 PM
EricWF updated this revision to Diff 91447.Mar 10 2017, 6:46 PM

Merge with master.

EricWF closed this revision.Mar 10 2017, 6:47 PM