- 21 Sep, 2015 1 commit
-
-
littledan authored
ES2015 specifies very particular semantics for functions defined in blocks. In strict mode, it is simply a lexical binding scoped to that block. In sloppy mode, in addition to that lexical binding, there is a var-style binding in the outer scope, which is overwritten with the local binding when the function declaration is evaluated, *as long as* introducing ths var binding would not create a var/let conflict in the outer scope. This patch implements the semantics by introducing a DelegateStatement, which is initially filled in with the EmptyStatement and overwritten with the assignment when the scope is closed out and it can be checked that there is no conflict. This patch is tested with a new mjsunit test, and I tried staging it and running test262, finding that the tests that we have disabled due to lack of Annex B support now pass. R=adamk,rossberg LOG=Y BUG=v8:4285 Review URL: https://codereview.chromium.org/1332873003 Cr-Commit-Position: refs/heads/master@{#30842}
-
- 12 Aug, 2015 2 commits
-
-
littledan authored
This patch strengthens testing of classes by verifying that the binding that they export externally follows block scoping, as opposed to var-style scoping. The tests are based on existing tests for let and const. R=adamk LOG=N BUG=v8:3305 Review URL: https://codereview.chromium.org/1286923002 Cr-Commit-Position: refs/heads/master@{#30140}
-
littledan authored
In an initial attempt to implement sloppy mode lexical bindings, functions were made lexically scoped in sloppy mode. However, the ES2015 spec says that they need an additional hoisted var binding, and further, it's not clear when we'll implement that behavior or whether it's web-compatible. This patch splits off function block scoping into a new, separate flag called --harmony_sloppy_function. This change will enable the possibility of testing and shipping this feature separately from other block scoping-related features which don't have the same risks. BUG=v8:4285 R=adamk LOG=N Review URL: https://codereview.chromium.org/1282093002 Cr-Commit-Position: refs/heads/master@{#30122}
-
- 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}
-
- 10 Jul, 2015 1 commit
-
-
arv authored
With --harmony-sloppy we can get to a runtime store in the presence of an eval. We therefor need to check that the value is not the hole which is used to enforce TDZ. BUG=v8:4284 LOG=N R=rossberg@chromium.org, littledan@chromium.org Review URL: https://codereview.chromium.org/1214733013 Cr-Commit-Position: refs/heads/master@{#29577}
-
- 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}
-
- 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}
-
- 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
-
- 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
-
- 25 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
This implements block scoped 'const' declared variables in harmony mode. They have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing uninitialized 'const' bindings in throws a ReferenceError. As for 'let' bindings, the semantics of 'const' bindings in global scope is not correctly implemented yet. Furthermore assignments to 'const's are silently ignored. Another CL will introduce treatment of those assignments as early errors. Review URL: http://codereview.chromium.org/7992005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Oct, 2011 1 commit
-
-
rossberg@chromium.org authored
Shorten --harmony-block-scoping to --harmony-scoping. R=keuchel@chromium.org BUG= TEST= Review URL: http://codereview.chromium.org/8226017 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9589 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST=test/mjsunit/harmony/block-let-semantics.js Review URL: http://codereview.chromium.org/8118032 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9541 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST=mjsunit/harmony/block-let-semantics.js Review URL: http://codereview.chromium.org/7671042 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9070 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-