- 08 Apr, 2016 1 commit
-
-
adamk authored
These were all on by default in M49 without complaint. R=littledan@chromium.org Review URL: https://codereview.chromium.org/1858943002 Cr-Commit-Position: refs/heads/master@{#35342}
-
- 22 Mar, 2016 1 commit
-
-
adamk authored
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations are no more. This lets us remove a bunch of code from many parts of the codebase. In this patch, I remove parser support for generating legacy const variables from const declarations. This also removes the special "illegal declaration" bit from Scope, which has ripples into all compiler backends. Also gone are any tests which relied on legacy const declarations. Note that we do still generate a Variable in mode CONST_LEGACY in one case: function name bindings in sloppy mode. The likely fix there is to add a new Variable::Kind for this case and handle it appropriately for stores in each backend, but I leave that for a later patch to make this one completely subtractive. Review URL: https://codereview.chromium.org/1819123002 Cr-Commit-Position: refs/heads/master@{#35002}
-
- 03 Feb, 2016 1 commit
-
-
adamk authored
This removes --harmony-completion, --harmony-concat-spreadable, and --harmony-tolength and moves the appropriate tests from harmony/ to es6/. Review URL: https://codereview.chromium.org/1667453002 Cr-Commit-Position: refs/heads/master@{#33712}
-
- 08 Oct, 2015 1 commit
-
-
neis authored
This CL depends on #1362363002. R=rossberg BUG= Review URL: https://codereview.chromium.org/1361403003 Cr-Commit-Position: refs/heads/master@{#31180}
-
- 25 Jul, 2015 1 commit
-
-
littledan authored
--harmony_sloppy includes behavior to turn on sloppy mode lexical bindings. Before this patch, it also included a way to parse let which is likely web-incompatible (let is disallowed as an identifier). This patch splits off the let parsing from the more general block scoping code, so that block scoping can be developed independently. R=adamk LOG=N BUG=v8:3305 Review URL: https://codereview.chromium.org/1255013002 Cr-Commit-Position: refs/heads/master@{#29855}
-
- 08 Jul, 2015 1 commit
-
-
arv authored
Allow let in sloppy mode with --harmony-sloppy Allow ES'15 const in sloppy mode with --harmony-sloppy --no-legacy-const Functions in block are not done yet. They are only let bound in the block at this point. BUG=v8:3305, v8:2198 LOG=N R=littledan@chromium.org, rossberg@chromium.org, adamk@chromium.org Review URL: https://codereview.chromium.org/1219853004 Cr-Commit-Position: refs/heads/master@{#29536}
-
- 18 Jun, 2015 1 commit
-
-
conradw authored
Currently, the desugaring of for loops of the form for (let/const ...; bla; bla) causes them to always have a completion value of 1, regardless of whether the loop body is executed or not. This CL fixes this, realigning initializer blocks as a more general purpose way to avoid the completion value rewriter (since that's all they really do anyway). BUG= Review URL: https://codereview.chromium.org/1177053006 Cr-Commit-Position: refs/heads/master@{#29108}
-
- 13 Mar, 2015 1 commit
-
-
dslomov authored
We have been shipping harmony scoping for 2 Chrome releases now (M41 and M42). Time to remove the flag. R=rossberg@chromium.org LOG=Y Review URL: https://codereview.chromium.org/1007783002 Cr-Commit-Position: refs/heads/master@{#27187}
-
- 27 Feb, 2015 1 commit
-
-
arv authored
The test didn't call the test function. BUG=v8:3932 LOG=N TBR=ulan@chromium.org Review URL: https://codereview.chromium.org/964993002 Cr-Commit-Position: refs/heads/master@{#26927}
-
- 17 Jun, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/338363002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 May, 2014 1 commit
-
-
ulan@chromium.org authored
BUG=v8:2198 LOG=N TEST=mjsunit/harmony/block-for R=rossberg@chromium.org Review URL: https://codereview.chromium.org/292743009 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21480 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
This CL introduces a third mode next to the non-strict (henceforth called 'classic mode') and 'strict mode' which is called 'extended mode' as in the current ES.next specification drafts. The extended mode is based on the 'strict mode' and adds new functionality to it. This means that most of the semantics of these two modes coincide. The 'extended mode' is entered instead of the 'strict mode' during parsing when using the 'strict mode' directive "use strict" and when the the harmony-scoping flag is active. This should be changed once it is fully specified how the 'extended mode' is entered. This change introduces a new 3 valued enum LanguageMode (see globals.h) corresponding to the modes which is mostly used by the frontend code. This includes the following components: * (Pre)Parser * Compiler * SharedFunctionInfo, Scope and ScopeInfo * runtime functions: StoreContextSlot, ResolvePossiblyDirectEval, InitializeVarGlobal, DeclareGlobals The old enum StrictModeFlag is still used in the backend when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes: * SetProperty runtime function, Delete builtin * StoreIC and KeyedStoreIC * StubCache Review URL: http://codereview.chromium.org/8417035 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
TEST=mjsunit/harmony/block-for.js Review URL: http://codereview.chromium.org/7837028 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9658 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-