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

for(const x in y) #541

Closed
classilla opened this Issue Jan 12, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@classilla
Copy link
Owner

classilla commented Jan 12, 2019

This is needed for full functionality in Github's current release, and probably fixes other sites. Unfortunately it also seems to have been fixed by the frontend binding rewrite that is the crux of #533.

It may be possible to hack in something that allows const as a synonym for var as a temporary fix. The underlying issues, which were never fully repaired, are https://bugzilla.mozilla.org/show_bug.cgi?id=449811 and https://bugzilla.mozilla.org/show_bug.cgi?id=1101653 .

@classilla

This comment has been minimized.

Copy link
Owner Author

classilla commented Jan 12, 2019

In Parser.cpp, look at lines 4585 and 4791. Then, in BytecodeEmitter.cpp, fix the assertions in lines 5499 and remove the assertion at 5521. This should be enough to get const treated as let which should have similar enough semantics for a first pass. However, this is too risky to put in FPR12.

@roytam1

This comment has been minimized.

Copy link

roytam1 commented Jan 23, 2019

so these changes "hackfixes" for(const x in y) problems:

diff --git a/js/src/frontend/BytecodeEmitter.cpp b/js/src/frontend/BytecodeEmitter.cpp
index df0d8a7b0..dafb61f05 100644
--- a/js/src/frontend/BytecodeEmitter.cpp
+++ b/js/src/frontend/BytecodeEmitter.cpp
@@ -5496,7 +5496,7 @@ BytecodeEmitter::emitIterator()
 bool
 BytecodeEmitter::emitForInOrOfVariables(ParseNode* pn)
 {
-    MOZ_ASSERT(pn->isKind(PNK_VAR) || pn->isKind(PNK_LET));
+    MOZ_ASSERT(pn->isKind(PNK_VAR) || pn->isKind(PNK_LET) || pn->isKind(PNK_CONST));
 
     // ES6 specifies that loop variables get a fresh binding in each iteration.
     // This is currently implemented for C-style for(;;) loops, but not
@@ -5518,7 +5518,7 @@ BytecodeEmitter::emitForInOrOfVariables(ParseNode* pn)
         if (!emitVariables(pn, DefineVars))
             return false;
     } else {
-        MOZ_ASSERT(pn->isKind(PNK_LET));
+        MOZ_ASSERT(pn->isKind(PNK_LET) || pn->isKind(PNK_CONST));
         if (!emitVariables(pn, InitializeVars))
             return false;
     }
diff --git a/js/src/frontend/Parser.cpp b/js/src/frontend/Parser.cpp
index 5830e7d90..3d6757fd9 100644
--- a/js/src/frontend/Parser.cpp
+++ b/js/src/frontend/Parser.cpp
@@ -4583,10 +4583,10 @@ Parser<ParseHandler>::declarationPattern(Node decl, TokenKind tt, BindData<Parse
         if (*forHeadKind != PNK_FORHEAD) {
             // |for (const ... in ...);| and |for (const ... of ...);| are
             // syntax errors for now.  We'll fix this in bug 449811.
-            if (handler.declarationIsConst(decl)) {
+            /*if (handler.declarationIsConst(decl)) {
                 report(ParseError, false, pattern, JSMSG_BAD_CONST_DECL);
                 return null();
-            }
+            }*/
 
             if (!checkDestructuringPattern(data, pattern))
                 return null();
@@ -4788,7 +4788,7 @@ Parser<ParseHandler>::declarationName(Node decl, TokenKind tt, BindData<ParseHan
             if (isForIn || isForOf) {
                 // XXX Uncomment this when fixing bug 449811.  Until then,
                 //     |for (const ... in/of ...)| remains an error.
-                //constRequiringInitializer = false;
+                constRequiringInitializer = false;
 
                 *forHeadKind = isForIn ? PNK_FORIN : PNK_FOROF;
             } else {

and now complaining async/await keyword.
xref: #521

roytam1 added a commit to roytam1/mozilla45esr that referenced this issue Feb 1, 2019

@classilla

This comment has been minimized.

Copy link
Owner Author

classilla commented Feb 6, 2019

This isn't worth it, might regress other code, and doesn't fix enough to get Github working properly. Wontfixing for TenFourFox.

@classilla classilla closed this Feb 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment