Emit 'for...of' statements in ES3/ES5 #2207

JsonFreeman · 2015-03-05T03:40:23Z

This is the downlevel emit for 'for...of' loops in ES3/ES5.

The following ES6 code:

for (var v of expr) { }

will be emitted as:

for (var _i = 0, _a = expr; _i < _a.length; _i++) {
    var v = _a[_i];
}

It works in all forms, including with destructuring.

Still pending is the type check work for this downlevel emit. Also, using a for...of loop below ES6 still errors, but it now emits correctly. I will send out the error removal in another change.

…ames

sebmck · 2015-03-06T06:36:29Z

This only takes into consideration arrays. How do you plan on supporting all iterables?

JsonFreeman · 2015-03-06T18:29:31Z

This works for arrays and strings. Other iterables will not be supported for ES3/ES5

JsonFreeman · 2015-03-06T18:34:20Z

And I'm going to add type checking to only allow arrays in the loop (for ES3/5) and strings (for ES5).

ahejlsberg · 2015-03-09T18:17:25Z

src/compiler/emitter.ts

@@ -1639,10 +1639,12 @@ module ts {
            }

            if (root) {
+                currentSourceFile = root;
                emit(root);


Why doesn't the emit method set currentSourceFile? Seems hacky to do it here.

It used to. This change was @CyrusNajmabadi's idea, but the purpose is to set it earlier, so that it's easy to see it. In other words, there is no reason to wait until emit to set currentSourceFile. If you feel strongly, I can change it back.

It would also mean that the 'emit' method needs to check what type of node it has. Something it doesn't do today. It would also need to do this for the sourcemap/non-sourcemap case. This is a simpler way to accomplish all that.

I don't like it. If anything, you should set it here and emit should take no parameters and operate on currentSourceFile. But I prefer the way it was.

The problem with the previous form was that setting current would happen far down the line. i.e. only once we actually got around to calling 'emitSourceFile'. That meant that between the call to 'emit' and the eventual call to emitSourceFile, you had a time when there was no 'currentSourceFile', which could break anyone who tried to use it for any purpose.

This approach ensures that currentSourceFile is set hte moment we start processing an actual source file.

The alternative is to move this check/set into 'emit'. However, that means that ever call to emit need to immediately check what type of node it is emitting, and then set currentSourceFile if it's a sourceFile. Given how often emit is called, it seems better to just set the sourceFile the moment we know we're emitting a file, and hten have it correctly set for all code that runs from that point on.

Ok I added emitSourceFile, which sets the currentSourceFile, and then calls emit on the source file. The old emitSourceFile has been renamed to emitSourceFileNode.

… for-ofES5 Conflicts: tests/baselines/reference/parserES5ForOfStatement18.js tests/baselines/reference/parserES5ForOfStatement21.js

ahejlsberg · 2015-03-09T18:21:27Z

src/compiler/checker.ts

@@ -10891,9 +10891,9 @@ module ts {
            getSymbolDisplayBuilder().buildTypeDisplay(getReturnTypeOfSignature(signature), writer, enclosingDeclaration, flags);
        }

-        function isUnknownIdentifier(location: Node, name: string): boolean {
+        function isUnknownIdentifier(location: Node, name: string, sourceFile: SourceFile): boolean {


Is sourceFile just an optimization? Also, the order of arguments should be sourceFile, location, name.

sourceFile is not just an optimization. It is necessary. The reason is that location may be a synthesized node, in which case it will not have a proper parent chain with which to obtain the source file.

I will change the argument order.

But location is used as a parameter to resolveName which crawls up the parent chain. How's that going to work if it has no parent?

That is a good point. It is possible that there is a bug here.

Looking at the loop in resolveName, if the location at any point does not have a parent, the the function will assume that it's at the global scope. It will try to find the name at the global scope, and will return whether it found it. So I'm not sure it's possible to observe a problem because of this behavior.

That said, I agree with you that it's appropriate for the caller to rely on this behavior. So I think we should discuss what should happen for synthesized nodes.

I changed this so it no longer takes a source file. It now asserts that the location passed in is not synthesized.

In the emitter, I've changed emitDestructuring to take an optional parameter lowestNonSynthesizedAncestor, and I've added a comment as to how it should be used:

/** * If the root has a chance of being a synthesized node, callers should also pass a value for * lowestNonSynthesizedAncestor. This should be an ancestor of root, it should not be synthesized, * and there should not be a lower ancestor that introduces a scope. This node will be used as the * location for ensuring that temporary names are unique. */

CyrusNajmabadi · 2015-03-09T21:34:52Z

src/compiler/emitter.ts

-                        emitDestructuringAssignment(target, value);
-                    }
-                    else {
+                function emitAssignmentExpression(root: ExpressionStatement | BinaryExpression) {


Just take the binary expression, and a 'parent' node.

CyrusNajmabadi · 2015-03-09T21:35:13Z

👍

ahejlsberg · 2015-03-09T21:42:33Z

src/compiler/emitter.ts

+                function emitAssignmentExpression(root: ExpressionStatement | BinaryExpression) {
+                    // Synthesized nodes will not have parents, so the ExpressionStatements will have to be passed
+                    // in directly. Otherwise, it will crash when we access the parent of a synthesized binary expression.
+                    var emitParenthesized = root.kind !== SyntaxKind.ExpressionStatement && root.parent.kind !== SyntaxKind.ExpressionStatement;


Could you just take an emitParenthesized parameter instead of this synthetic business?

I will take a look at doing that. An alternative is what Cyrus mentioned, which is to pass in the parent if the node is synthesized.

Don't think the parent is used for anything other than determining whether to parenthesize. No reason to make it more cryptic than need be.

Yeah I think it can work with just a boolean to say whether it's parenthesized.

Ok I added a required boolean parameter called isAssignmentExpressionStatement. And I am checking this instead of checking the parent.

… for-ofES5

Emit 'for...of' statements in ES3/ES5

claudeduguay · 2015-08-31T23:57:56Z

I'd love to see support to Iterators here. In principle, the system is type-aware so the emitter only has to generate a while loop to support this capability in ES3/ES5.

JsonFreeman · 2015-09-01T04:09:12Z

Code generation for iterators will only work if there is a polyfill for Symbol.iterator, which TS does not provide currently. Additionally, the expectation is that pre-ES6 code authors who want to use for..of are just trying to iterate over an array, though this may become less true over time.

jamesmoey · 2015-09-14T14:17:31Z

AngularJs2 currently uses iterator in QueryList which will not work in Typescript. Please support iterator.

danquirk · 2015-09-14T19:51:15Z

@jamesmoey please log an issue with an example. Old pull requests are not really the place to track these sorts of requests, thanks.

olydis · 2015-10-30T13:11:01Z

Not sure if the playground uses the most recent version but there is an inconsistency regarding the emitted ES3/ES5 code:

var x = [3, 3, 3];
for (var i of x)
{
    x = [2, 2];
    console.log(i);
}

compiles to

var x = [3, 3, 3];
for (var _i = 0; _i < x.length; _i++) {
    var i = x[_i];
    x = [2, 2];
    console.log(i);
}

printing

3
2

instead of (ES6 semantics)

3
3
3

On the other hand, merely adding parentheses:

var x = [3, 3, 3];
for (var i of (x))
{
    x = [2, 2];
    console.log(i);
}

correctly compiles to

var x = [3, 3, 3];
for (var _a = 0, _b = (x); _a < _b.length; _a++) {
    var i = _b[_a];
    x = [2, 2];
    console.log(i);
}

giving the expected output.

JsonFreeman · 2015-10-30T17:42:45Z

You're right that's a bug. Please log a new issue for this.

JsonFreeman added 14 commits March 4, 2015 19:34

Emit 'for...of' loop when LHS is a var

e417e1d

Make createTempVariable call into generateUniqueNameForLocation

76e9b6a

Add tests for 'for...of' emit when LHS is a var

61224e9

Accept baselines

5a87864

Remove tempCount

9b76a02

Emit for...of when LHS is expression

f915efa

Emit 'for...of' statements with let/const initializers

a0f108c

Support destructuring in 'for...of' loops

a99449a

Accept baselines

9288424

Revert change to createTempVariable

4d32650

Fix createTempVariable to always record the name in the currentScopeN…

4bb0587

…ames

Do not create a temp for RHS if it's an identifier

905f350

Add tests for destructuring 'for...of'

ed3ab96

Accept error baselines and API breaks

946dc0e

msftclas added the cla-not-required label Mar 5, 2015

JsonFreeman removed the cla-not-required label Mar 5, 2015

JsonFreeman added 2 commits March 5, 2015 11:47

Fix sourcemaps for 'for...of' and no source maps for synthesized nodes

fecd20a

Minor baseline adjustment

835c84f

DickvdBrink mentioned this pull request Mar 8, 2015

Suggestion: 'for..of' #7

Closed

ahejlsberg reviewed Mar 9, 2015
View reviewed changes

Merge branch 'master' of https://github.com/Microsoft/TypeScript into…

a27fbff

… for-ofES5 Conflicts: tests/baselines/reference/parserES5ForOfStatement18.js tests/baselines/reference/parserES5ForOfStatement21.js

ahejlsberg reviewed Mar 9, 2015
View reviewed changes

CyrusNajmabadi reviewed Mar 9, 2015
View reviewed changes

ahejlsberg reviewed Mar 9, 2015
View reviewed changes

JsonFreeman added 3 commits March 9, 2015 19:45

Address PR feedback

b15d8aa

Merge branch 'master' of https://github.com/Microsoft/TypeScript into…

1349a19

… for-ofES5

Fix call to emitNode after merge with master

f389aef

JsonFreeman added a commit that referenced this pull request Mar 10, 2015

Merge pull request #2207 from Microsoft/for-ofES5

07a893d

Emit 'for...of' statements in ES3/ES5

JsonFreeman merged commit 07a893d into master Mar 10, 2015

JsonFreeman deleted the for-ofES5 branch March 10, 2015 19:13

adidahiya mentioned this pull request Apr 20, 2015

ES6 for-of iteration syntax palantir/tslint#370

Closed

olydis mentioned this pull request Oct 30, 2015

Wrong ES3/ES5 code when iterated identifier is reassigned in a 'for...of' statement #5475

Closed

JakubJagoda mentioned this pull request Feb 7, 2016

"Export equals" syntax when used with Webpack and Babel DefinitelyTyped/DefinitelyTyped#8005

Closed

microsoft locked and limited conversation to collaborators Jun 18, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Emit 'for...of' statements in ES3/ES5 #2207

Emit 'for...of' statements in ES3/ES5 #2207

JsonFreeman commented Mar 5, 2015

sebmck commented Mar 6, 2015

JsonFreeman commented Mar 6, 2015

JsonFreeman commented Mar 6, 2015

ahejlsberg Mar 9, 2015

JsonFreeman Mar 9, 2015

CyrusNajmabadi Mar 9, 2015

ahejlsberg Mar 9, 2015

CyrusNajmabadi Mar 9, 2015

JsonFreeman Mar 9, 2015

ahejlsberg Mar 9, 2015

JsonFreeman Mar 9, 2015

ahejlsberg Mar 9, 2015

JsonFreeman Mar 9, 2015

JsonFreeman Mar 9, 2015

JsonFreeman Mar 10, 2015

CyrusNajmabadi Mar 9, 2015

CyrusNajmabadi commented Mar 9, 2015

ahejlsberg Mar 9, 2015

JsonFreeman Mar 9, 2015

ahejlsberg Mar 9, 2015

JsonFreeman Mar 9, 2015

JsonFreeman Mar 10, 2015

claudeduguay commented Aug 31, 2015

JsonFreeman commented Sep 1, 2015

jamesmoey commented Sep 14, 2015

danquirk commented Sep 14, 2015

olydis commented Oct 30, 2015

JsonFreeman commented Oct 30, 2015

Emit 'for...of' statements in ES3/ES5 #2207

Emit 'for...of' statements in ES3/ES5 #2207

Conversation

JsonFreeman commented Mar 5, 2015

sebmck commented Mar 6, 2015

JsonFreeman commented Mar 6, 2015

JsonFreeman commented Mar 6, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CyrusNajmabadi commented Mar 9, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

claudeduguay commented Aug 31, 2015

JsonFreeman commented Sep 1, 2015

jamesmoey commented Sep 14, 2015

danquirk commented Sep 14, 2015

olydis commented Oct 30, 2015

JsonFreeman commented Oct 30, 2015