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

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

R=yangguo@chromium.org
BUG=

Review URL: https://codereview.chromium.org/245963006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org
BUG=v8:2322

Review URL: https://codereview.chromium.org/11035054

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

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

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

Review URL: http://codereview.chromium.org/7835027

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9158 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
TEST=mjsunit/harmony/block-leave.js

Review URL: http://codereview.chromium.org/7792100

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9157 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

'Let's inside a 'with' would initialize the variable
using the StoreContextSlot runtime function which
would fail because it checks that the variable does
not hold the hole value.

Review URL: http://codereview.chromium.org/7792098

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9156 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
TEST=

Review URL: http://codereview.chromium.org/7825006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Implementation of the harmony block scoped let bindings as proposed here:
http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings

Changes to the syntax are explained there. They are active under the
harmony_block_scoping_ flag in the parser.

Review URL: http://codereview.chromium.org/7616009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
TEST=

Review URL: http://codereview.chromium.org/7549008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00