Introduce extended mode.

Introduce extended mode.

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

Committed: http://code.google.com/p/v8/source/detail?r=10062

[Steven, 2011-10-28 17:38:00]

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. Will change that once it is fully specified how
the extended mode is entered.

For now I've used the name 'is_strict_or_extended_mode'
for the predicate which tests against non classic modes.
I'm open for suggestions, but IMO it doesn't occur too
often in the source.

Please take a look.

[rossberg, 2011-11-08 15:02:45]

http://codereview.chromium.org/8417035/diff/11001/src/ast.h
File src/ast.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/ast.h#newcode1635
src/ast.h:1635: bool is_strict_or_extended_mode() const { return
!is_classic_mode(); }
I forgot what exactly we concluded earlier, but this really seems redundant if
we have the former.

http://codereview.chromium.org/8417035/diff/11001/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/8417035/diff/11001/src/compiler.cc#newcode616
src/compiler.cc:616: language_mode == EXTENDED_MODE);
These assertions can be simplified, too.

http://codereview.chromium.org/8417035/diff/11001/src/compiler.h
File src/compiler.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/compiler.h#newcode57
src/compiler.h:57: bool is_strict_or_extended_mode() const { return
!is_classic_mode(); }
Same here.

http://codereview.chromium.org/8417035/diff/11001/src/compiler.h#newcode86
src/compiler.h:86: language_mode == EXTENDED_MODE);
All this asserts is this->language_mode() <= language_mode, right? I think you
can simplify the two assertions to

ASSERT(this->lm == lm || this->lm == CLASSIC || lm == EXTENDED)

http://codereview.chromium.org/8417035/diff/11001/src/full-codegen.h
File src/full-codegen.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/full-codegen.h#newcode530
src/full-codegen.h:530: bool is_strict_or_extended_mode() {
As before.

http://codereview.chromium.org/8417035/diff/11001/src/objects-inl.h
File src/objects-inl.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/objects-inl.h#newcode3499
src/objects-inl.h:3499: BOOL_GETTER(SharedFunctionInfo, compiler_hints,
is_strict_or_extended_mode,
And here.

http://codereview.chromium.org/8417035/diff/11001/src/preparser.h
File src/preparser.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/preparser.h#newcode589
src/preparser.h:589: bool is_strict_or_extended_mode() {
And here...

http://codereview.chromium.org/8417035/diff/11001/src/scopes.h
File src/scopes.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/scopes.h#newcode196
src/scopes.h:196: language_mode_ = FLAG_strict_mode ? language_mode :
CLASSIC_MODE;
Does such a flag still make sense given the new language modes?

http://codereview.chromium.org/8417035/diff/11001/src/scopes.h#newcode249
src/scopes.h:249: bool is_strict_or_extended_mode() const {
And one more.

http://codereview.chromium.org/8417035/diff/11001/test/mjsunit/harmony/debug-...
File test/mjsunit/harmony/debug-blockscopes.js (left):

http://codereview.chromium.org/8417035/diff/11001/test/mjsunit/harmony/debug-...
test/mjsunit/harmony/debug-blockscopes.js:92: assertPropertiesEqual(this,
scope.scopeObject().value());
You can still get the global object by defining s.th like

var global_object = this

on the toplevel.

[Steven, 2011-11-08 16:13:48]

PTAL.

http://codereview.chromium.org/8417035/diff/11001/src/ast.h
File src/ast.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/ast.h#newcode1635
src/ast.h:1635: bool is_strict_or_extended_mode() const { return
!is_classic_mode(); }
On 2011/11/08 15:02:46, rossberg wrote:
> I forgot what exactly we concluded earlier, but this really seems redundant if
> we have the former.

Done.

http://codereview.chromium.org/8417035/diff/11001/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/8417035/diff/11001/src/compiler.cc#newcode616
src/compiler.cc:616: language_mode == EXTENDED_MODE);
On 2011/11/08 15:02:46, rossberg wrote:
> These assertions can be simplified, too.

Done.

http://codereview.chromium.org/8417035/diff/11001/src/compiler.h
File src/compiler.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/compiler.h#newcode57
src/compiler.h:57: bool is_strict_or_extended_mode() const { return
!is_classic_mode(); }
On 2011/11/08 15:02:46, rossberg wrote:
> Same here.

Done.

http://codereview.chromium.org/8417035/diff/11001/src/compiler.h#newcode86
src/compiler.h:86: language_mode == EXTENDED_MODE);
On 2011/11/08 15:02:46, rossberg wrote:
> All this asserts is this->language_mode() <= language_mode, right? I think you
> can simplify the two assertions to
> 
> ASSERT(this->lm == lm || this->lm == CLASSIC || lm == EXTENDED)

Done.

http://codereview.chromium.org/8417035/diff/11001/src/full-codegen.h
File src/full-codegen.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/full-codegen.h#newcode530
src/full-codegen.h:530: bool is_strict_or_extended_mode() {
On 2011/11/08 15:02:46, rossberg wrote:
> As before.

Done.

http://codereview.chromium.org/8417035/diff/11001/src/objects-inl.h
File src/objects-inl.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/objects-inl.h#newcode3499
src/objects-inl.h:3499: BOOL_GETTER(SharedFunctionInfo, compiler_hints,
is_strict_or_extended_mode,
On 2011/11/08 15:02:46, rossberg wrote:
> And here.

Done.

http://codereview.chromium.org/8417035/diff/11001/src/preparser.h
File src/preparser.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/preparser.h#newcode589
src/preparser.h:589: bool is_strict_or_extended_mode() {
On 2011/11/08 15:02:46, rossberg wrote:
> And here...

Done.

http://codereview.chromium.org/8417035/diff/11001/src/scopes.h
File src/scopes.h (right):

http://codereview.chromium.org/8417035/diff/11001/src/scopes.h#newcode196
src/scopes.h:196: language_mode_ = FLAG_strict_mode ? language_mode :
CLASSIC_MODE;
Not really. Removing it.
On 2011/11/08 15:02:46, rossberg wrote:
> Does such a flag still make sense given the new language modes?

http://codereview.chromium.org/8417035/diff/11001/src/scopes.h#newcode249
src/scopes.h:249: bool is_strict_or_extended_mode() const {
On 2011/11/08 15:02:46, rossberg wrote:
> And one more.

Done.

http://codereview.chromium.org/8417035/diff/11001/test/mjsunit/harmony/debug-...
File test/mjsunit/harmony/debug-blockscopes.js (left):

http://codereview.chromium.org/8417035/diff/11001/test/mjsunit/harmony/debug-...
test/mjsunit/harmony/debug-blockscopes.js:92: assertPropertiesEqual(this,
scope.scopeObject().value());
On 2011/11/08 15:02:46, rossberg wrote:
> You can still get the global object by defining s.th like
> 
> var global_object = this
> 
> on the toplevel.

Done.

[rossberg, 2011-11-09 12:15:29]

lgtm

http://codereview.chromium.org/8417035/diff/17001/src/objects.cc
File src/objects.cc (right):

http://codereview.chromium.org/8417035/diff/17001/src/objects.cc#newcode7278
src/objects.cc:7278: map() == global_context->function_map());
Nit: These two assertions could be a single

map() == (classic() ? f_map : strict_f_map)

http://codereview.chromium.org/8417035/diff/17001/test/mjsunit/harmony/debug-...
File test/mjsunit/harmony/debug-blockscopes.js (right):

http://codereview.chromium.org/8417035/diff/17001/test/mjsunit/harmony/debug-...
test/mjsunit/harmony/debug-blockscopes.js:92: // Check the global object when
hitting the global scope.
Reinserted at the wrong place. ;-)

[Rico, 2011-11-14 14:58:52]

First round

http://codereview.chromium.org/8417035/diff/29001/src/arm/full-codegen-arm.cc
File src/arm/full-codegen-arm.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/arm/full-codegen-arm.cc...
src/arm/full-codegen-arm.cc:2196: // Push the receiver of the enclosing
function.
we still call runtime!

http://codereview.chromium.org/8417035/diff/29001/src/arm/full-codegen-arm.cc...
src/arm/full-codegen-arm.cc:2200: // Push the language mode.
Actually, I also sort of like the existing comment here, it is useful and still
true, just change strict mode flat to language mode.

http://codereview.chromium.org/8417035/diff/29001/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/arm/lithium-codegen-arm...
src/arm/lithium-codegen-arm.cc:2292: Handle<Code> ic =
(instr->strict_mode_flag() == kStrictMode)
Can't we arrive here with extended mode flag? if so, should this be:
Handle<Code> ic = (instr->strict_mode_flag() == kNonStrictMode)
    ? isolate()->builtins()->StoreIC_Initialize()
    ? isolate()->builtins()->StoreIC_Initialize_Strict();
Same question for several occurrences below

http://codereview.chromium.org/8417035/diff/29001/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/compiler.cc#newcode606
src/compiler.cc:606: // After parsing we know function's language mode. Remember
it.
we know the functions's ...
         ^

http://codereview.chromium.org/8417035/diff/29001/src/ia32/full-codegen-ia32.cc
File src/ia32/full-codegen-ia32.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/ia32/full-codegen-ia32....
src/ia32/full-codegen-ia32.cc:2148: // Push the language mode.
same comment as on arm

[Rico, 2011-11-15 08:25:07]

Second round of comments

http://codereview.chromium.org/8417035/diff/29001/src/globals.h
File src/globals.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/globals.h#newcode364
src/globals.h:364: enum LanguageMode {
could we add a few lines about the modes, what they mean and why we have them

http://codereview.chromium.org/8417035/diff/29001/src/mips/full-codegen-mips.cc
File src/mips/full-codegen-mips.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/mips/full-codegen-mips....
src/mips/full-codegen-mips.cc:2267: __ lw(a1, MemOperand(fp, receiver_offset *
kPointerSize));
As on arm, I actually think that the original comments gives value

http://codereview.chromium.org/8417035/diff/29001/src/objects-inl.h
File src/objects-inl.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/objects-inl.h#newcode3495
src/objects-inl.h:3495: ASSERT(this->language_mode() == CLASSIC_MODE ||
add comment here stating that the allowed transitions are:
CLASSIC_MODE -> STRICT_MODE
CLASSIC_MODE -> EXTENDED_MODE
STRICT_MODE -> EXTENDED_MODE

http://codereview.chromium.org/8417035/diff/29001/src/objects.h
File src/objects.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/objects.h#newcode4973
src/objects.h:4973: // Indicates whether the function is a classic mode
function.
I would add "(i.e., classic in the sense that we have non-strict semantics)"
after classic in this comment. V8 team members might not actually know what
classic means yet, so a clarification here would be good)

http://codereview.chromium.org/8417035/diff/29001/src/objects.h#newcode4977
src/objects.h:4977: inline bool is_extended_mode();
Also, please add a comment here (or below for language_mode()) explaining the
meaning of the 3 modes, I know this is in the commit message, but it is
cumbersome to go there. Please also do this in globals.h

http://codereview.chromium.org/8417035/diff/29001/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/parser.cc#newcode3716
src/parser.cc:3716: this, !top_scope_->is_classic_mode());
How about just having the mode in the class, everything is better than a bool
for an argument :-)

http://codereview.chromium.org/8417035/diff/29001/src/preparse-data.h
File src/preparse-data.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/preparse-data.h#newcode93
src/preparse-data.h:93: ) {
move ") {" up

http://codereview.chromium.org/8417035/diff/29001/src/preparser.h
File src/preparser.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/preparser.h#newcode421
src/preparser.h:421: : i::CLASSIC_MODE) {
indention

http://codereview.chromium.org/8417035/diff/29001/src/scopes.h
File src/scopes.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/scopes.h#newcode432
src/scopes.h:432: // This scope is a strict mode scope.
Update comment

http://codereview.chromium.org/8417035/diff/29001/src/x64/full-codegen-x64.cc
File src/x64/full-codegen-x64.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/x64/full-codegen-x64.cc...
src/x64/full-codegen-x64.cc:2093: // Push the language mode.
same comment as on arm,

[Steven, 2011-11-15 13:33:29]

I addressed your comments from both rounds. Please take another look.

http://codereview.chromium.org/8417035/diff/29001/src/arm/full-codegen-arm.cc
File src/arm/full-codegen-arm.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/arm/full-codegen-arm.cc...
src/arm/full-codegen-arm.cc:2196: // Push the receiver of the enclosing
function.
On 2011/11/14 14:58:52, Rico wrote:
> we still call runtime!

Done.

http://codereview.chromium.org/8417035/diff/29001/src/arm/full-codegen-arm.cc...
src/arm/full-codegen-arm.cc:2200: // Push the language mode.
The previously implemented behavior does not correspond to what's in the draft
spec and was put in there because of false assumptions that Andreas and I had.
In ES.next the same happens as in ES5, the eval code will be in the same mode
unless it starts with a declarative that changes it. So the comment is no true.

On 2011/11/14 14:58:52, Rico wrote:
> Actually, I also sort of like the existing comment here, it is useful and
still
> true, just change strict mode flat to language mode.

http://codereview.chromium.org/8417035/diff/29001/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/arm/lithium-codegen-arm...
src/arm/lithium-codegen-arm.cc:2292: Handle<Code> ic =
(instr->strict_mode_flag() == kStrictMode)
The extended mode is also represented by the kStrictMode value in the
StrictModeFlag enum. And it correctly should share the IC with the strict mode.
However, your question strongly suggests that kStrictMode should be renamed to
avoid confusion. I already planned that, but want to leave it to a renaming only
CL.

On 2011/11/14 14:58:52, Rico wrote:
> Can't we arrive here with extended mode flag? if so, should this be:
> Handle<Code> ic = (instr->strict_mode_flag() == kNonStrictMode)
>     ? isolate()->builtins()->StoreIC_Initialize()
>     ? isolate()->builtins()->StoreIC_Initialize_Strict();
> Same question for several occurrences below

http://codereview.chromium.org/8417035/diff/29001/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/compiler.cc#newcode606
src/compiler.cc:606: // After parsing we know function's language mode. Remember
it.
On 2011/11/14 14:58:52, Rico wrote:
> we know the functions's ...
>          ^

Done.

http://codereview.chromium.org/8417035/diff/29001/src/globals.h
File src/globals.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/globals.h#newcode364
src/globals.h:364: enum LanguageMode {
On 2011/11/15 08:25:07, Rico wrote:
> could we add a few lines about the modes, what they mean and why we have them 

Done.

http://codereview.chromium.org/8417035/diff/29001/src/ia32/full-codegen-ia32.cc
File src/ia32/full-codegen-ia32.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/ia32/full-codegen-ia32....
src/ia32/full-codegen-ia32.cc:2148: // Push the language mode.
On 2011/11/14 14:58:52, Rico wrote:
> same comment as on arm

Done.

http://codereview.chromium.org/8417035/diff/29001/src/mips/full-codegen-mips.cc
File src/mips/full-codegen-mips.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/mips/full-codegen-mips....
src/mips/full-codegen-mips.cc:2267: __ lw(a1, MemOperand(fp, receiver_offset *
kPointerSize));
On 2011/11/15 08:25:07, Rico wrote:
> As on arm, I actually think that the original comments gives value

Done.

http://codereview.chromium.org/8417035/diff/29001/src/objects-inl.h
File src/objects-inl.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/objects-inl.h#newcode3495
src/objects-inl.h:3495: ASSERT(this->language_mode() == CLASSIC_MODE ||
On 2011/11/15 08:25:07, Rico wrote:
> add comment here stating that the allowed transitions are:
> CLASSIC_MODE -> STRICT_MODE
> CLASSIC_MODE -> EXTENDED_MODE
> STRICT_MODE -> EXTENDED_MODE

Done.

http://codereview.chromium.org/8417035/diff/29001/src/objects.h
File src/objects.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/objects.h#newcode4973
src/objects.h:4973: // Indicates whether the function is a classic mode
function.
On 2011/11/15 08:25:07, Rico wrote:
> I would add "(i.e., classic in the sense that we have non-strict semantics)"
> after classic in this comment. V8 team members might not actually know what
> classic means yet, so a clarification here would be good)

Done.

http://codereview.chromium.org/8417035/diff/29001/src/objects.h#newcode4977
src/objects.h:4977: inline bool is_extended_mode();
On 2011/11/15 08:25:07, Rico wrote:
> Also, please add a comment here (or below for language_mode()) explaining the
> meaning of the 3 modes, I know this is in the commit message, but it is
> cumbersome to go there. Please also do this in globals.h

Done.

http://codereview.chromium.org/8417035/diff/29001/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/parser.cc#newcode3716
src/parser.cc:3716: this, !top_scope_->is_classic_mode());
On 2011/11/15 08:25:07, Rico wrote:
> How about just having the mode in the class, everything is better than a bool
> for an argument :-)

Done.

http://codereview.chromium.org/8417035/diff/29001/src/preparse-data.h
File src/preparse-data.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/preparse-data.h#newcode93
src/preparse-data.h:93: ) {
On 2011/11/15 08:25:07, Rico wrote:
> move ") {" up

Done.

http://codereview.chromium.org/8417035/diff/29001/src/preparser.h
File src/preparser.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/preparser.h#newcode421
src/preparser.h:421: : i::CLASSIC_MODE) {
On 2011/11/15 08:25:07, Rico wrote:
> indention

Done.

http://codereview.chromium.org/8417035/diff/29001/src/scopes.h
File src/scopes.h (right):

http://codereview.chromium.org/8417035/diff/29001/src/scopes.h#newcode432
src/scopes.h:432: // This scope is a strict mode scope.
On 2011/11/15 08:25:07, Rico wrote:
> Update comment

Done.

http://codereview.chromium.org/8417035/diff/29001/src/x64/full-codegen-x64.cc
File src/x64/full-codegen-x64.cc (right):

http://codereview.chromium.org/8417035/diff/29001/src/x64/full-codegen-x64.cc...
src/x64/full-codegen-x64.cc:2093: // Push the language mode.
On 2011/11/15 08:25:07, Rico wrote:
> same comment as on arm, 

Done.

[Rico, 2011-11-16 08:05:10]

LGTM