-
-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - Implement async functions using generators #2821
Conversation
Test262 conformance changes
Fixed tests (1):
|
Codecov Report
@@ Coverage Diff @@
## main #2821 +/- ##
==========================================
+ Coverage 51.32% 51.36% +0.04%
==========================================
Files 417 417
Lines 41356 41258 -98
==========================================
- Hits 21224 21194 -30
+ Misses 20132 20064 -68
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like good changes. Some nice refactors!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Looks good to me! :)
bors r+ |
This should hopefully fix more async/futures issues related to resuming execution in the future, since we can leverage generator logic to handle this for us. It changes the following: - Refactors `GeneratorContext` to handle context preparation. - Reuses the functionality of `GeneratorContext` in `Await`. - Removes `EarlyReturnType` in favour of a single `r#await` bool flag in `CallFrame`.
Pull request successfully merged into main. Build succeeded: |
Just some small improvements that increase the strictness of our generator state handling. Also rollbacks the implementation of `GeneratorValidate` because I forgot to remove it after I did modifications to #2821, and it doesn't make sense to have that if it isn't used by async functions.
This should hopefully fix more async/futures issues related to resuming execution in the future, since we can leverage generator logic to handle this for us.
It changes the following:
GeneratorContext
to handle context preparation.GeneratorContext
inAwait
.EarlyReturnType
in favour of a singler#await
bool flag inCallFrame
.