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
Parse using
declaration (explicit resource management)
#14968
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/53239/ |
lookaheadAhead.type === tt._of && | ||
lookaheadAhead.end - lookaheadAhead.start === 2 | ||
) { | ||
// using of 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.
In the worst scenario, we have to do triple lookahead to differentiate between using of of of
and using of of
.
@rbuckton Maybe we can forbid of
as a using binding in for-of
? So for (using of
must be a for-LHS and we don't have to peek more.
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.
Isn't it the same as let of of of
? Or is of
disallowed in that case?
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.
for ( [lookahead ∉ { let, async of }] LeftHandSideExpression[?Yield, ?Await] of AssignmentExpression[+In, ?Yield, ?Await] ) Statement[?Yield, ?Await, ?Return]
for-of has disabled let
and async
as LHS so for(let of of
must start a for-of with a let-binding of
. But using
comes after for-of so we have to recognize for(using of of)
as for-of with using
as LHS.
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.
Per tc39/proposal-explicit-resource-management#107, I will disallow of
as a for-using-of binding name, hopefully we will get rid of extra lookahead, too.
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.
There is now a PR that addresses this in the proposal repository.
99e5f75
to
6cd106e
Compare
// Ensure no line break between `using` and the first declarator | ||
iterator = (_, i: number) => { | ||
if (i === 0) { | ||
this._noLineTerminator = _noLineTerminator; |
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.
Shouldn't we also unset _noLineTerminator
after printing?
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.
Do you mean unset _noLineTerminator
after printing the using
keyword? The variable _noLineTerminator
here stores the value of this.noLineTerminator
before we print using
, and then we restore this._noLineTerminator
after the first declarator is printed.
3b45a7b
to
f9e12dd
Compare
{ | ||
using /* 1 */a = foo(), | ||
|
||
/* 2 */ | ||
b = foo(); | ||
/* 2 */b = foo(); | ||
} |
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.
The comments and indentation look fine.
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.
Just a small question: I noticed that the newly added containsEsc
property is only doing reads and no writes, is this expected?
The
So if we see an identifier, |
4f0e6ff
to
4a50d5e
Compare
using
declaration (explicit resource management)
This PR parses / generates the using declaration
introduced by the Explicit Resource Management proposal. We also create the new syntax plugin and add it to the babel-standalone.
I suggest reviewing this PR by commits.
/cc @rbuckton