Skip to content

Support top level "for await of" #37424

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
merged 7 commits into from
Jan 25, 2021
Merged

Conversation

hikarino-my
Copy link
Contributor

This PR will add supports for top level "for await of".

Fixes #37402

@sandersn
Copy link
Member

Reviewers list is broken, but @elibarzilay maybe you can look at this too.

@elibarzilay
Copy link
Contributor

(Rebased & resolved conflicts)

Copy link
Contributor

@elibarzilay elibarzilay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it should have more tests... Minor comments too.

Also, it would be good to verify that everything is fine after I rebased, since I needed to resolve conflicts.

@hikarino-my hikarino-my requested a review from elibarzilay July 26, 2020 18:33
@hikarino-my
Copy link
Contributor Author

@elibarzilay
Thank you for your review!
I've applied your suggestions to the code and added a test case so that it will check for positive case.

Comment on lines 38460 to 38467
const diagnostic = createDiagnosticForNode(forInOrOfStatement.awaitModifier, Diagnostics.A_for_await_of_statement_is_only_allowed_within_an_async_function_or_async_generator);
const func = getContainingFunction(forInOrOfStatement);
if (func && func.kind !== SyntaxKind.Constructor) {
Debug.assert((getFunctionFlags(func) & FunctionFlags.Async) === 0, "Enclosing function should never be an async function.");
const relatedInfo = createDiagnosticForNode(func, Diagnostics.Did_you_mean_to_mark_this_function_as_async);
addRelatedInfo(diagnostic, relatedInfo);
}
diagnostics.add(diagnostic);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since diagnostic is used twice here, didn't changed this section.

@hikarino-my
Copy link
Contributor Author

@elibarzilay @rbuckton @elibarzilay
Well, being kept waiting for +5 months with no review, currently i have no interest in this PR nor this project.
Since I'm away from this project for a long time, I'm not sure this works now.
I'll wait for your responses for a week but if there isn't i'm thinking of closing this PR.

if (!hasParseDiagnostics(sourceFile)) {
if (!isEffectiveExternalModule(sourceFile, compilerOptions)) {
diagnostics.add(createDiagnosticForNode(forInOrOfStatement.awaitModifier,
Diagnostics.await_expressions_are_only_allowed_at_the_top_level_of_a_file_when_that_file_is_a_module_but_this_file_has_no_imports_or_exports_Consider_adding_an_empty_export_to_make_this_file_a_module));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DanielRosenwasser would we want to reuse the phrase "await expressions" here, or should we have a more specific message for for await of?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Create a new diagnostic so we don't seem janky and lazy

'for await' loops are only allowed at the top level of a file when that file is a module, but this file...

Copy link
Member

@rbuckton rbuckton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. We may need to make the diagnostic message a little more generic to cover both await x and for-await-of, but we could easily do that in a follow-up PR if necessary.

@rbuckton
Copy link
Member

@typescript-bot test this
@typescript-bot user test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 20, 2021

Heya @rbuckton, I've started to run the parallelized community code test suite on this PR at d8a1db2. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 20, 2021

Heya @rbuckton, I've started to run the extended test suite on this PR at d8a1db2. You can monitor the build here.

@rbuckton
Copy link
Member

The RWC test suite looks good (failures are unrelated to this change). We're having some issues with our user test suite currently, but from what I can tell things look good here.

@DanielRosenwasser - Will we consider taking this for 4.2 RC, or should we wait to merge until after RC?

@rbuckton
Copy link
Member

rbuckton commented Jan 21, 2021

To clarify, this loosens a restriction specific to cases where we should allow it. It has no effect on run-time emit and would only remove errors that we shouldn't be reporting (we will still report errors for incorrect for-await-of in a script or in a --target/--module combination that doesn't support top-level await).

@rbuckton
Copy link
Member

I spoke with @DanielRosenwasser offline and we will be taking this for our 4.2 RC. Thanks @hikarinotomadoi for the contribution!

@rbuckton rbuckton merged commit 701493f into microsoft:master Jan 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Backlog Bug PRs that fix a backlog bug
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Top Level "for await" not supported, but should be
6 participants