-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Conversation
Reviewers list is broken, but @elibarzilay maybe you can look at this too. |
(Rebased & resolved conflicts) |
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 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.
@elibarzilay |
src/compiler/checker.ts
Outdated
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); |
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.
Since diagnostic
is used twice here, didn't changed this section.
@elibarzilay @rbuckton @elibarzilay |
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)); |
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.
@DanielRosenwasser would we want to reuse the phrase "await
expressions" here, or should we have a more specific message for for await of
?
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.
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...
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.
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.
@typescript-bot test this |
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? |
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 |
I spoke with @DanielRosenwasser offline and we will be taking this for our 4.2 RC. Thanks @hikarinotomadoi for the contribution! |
This PR will add supports for top level "for await of".
Fixes #37402