BUG=v8:4137
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#28946}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28827}

We used to only store the uses_super_property in the preparse data
logger. Let the logger use NeedsHomeObject instead.

BUG=v8:3768
LOG=N
R=wingo, adamk

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

Cr-Commit-Position: refs/heads/master@{#28806}

This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.

This is a revert of the revert 88b1c917

BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28769}

When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.

R=ulan@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28742}

Revert of [es6] Super call in arrows and eval (patchset #5 id:100001 of https://codereview.chromium.org/1146863007/)

Reason for revert:
Fails

http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/579/steps/Check/logs/super

Original issue's description:
> [es6] Super call in arrows and eval
>
> This splits the SuperReference AST node into SuperPropertyReference and
> SuperCallReference. The super call reference node consists of three
> unresolved vars to this, new.target and this_function. These gets
> declared when the right function is entered and if it is in use. The
> variables gets assigned in FullCodeGenerator::Generate.
>
> BUG=v8:3768
> LOG=N
> R=wingo@igalia.com, adamk@chromium.org
>
> Committed: https://crrev.com/673c0516ab96f24343bbb26e0afc2846b5a679df
> Cr-Commit-Position: refs/heads/master@{#28731}

TBR=wingo@igalia.com,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3768

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

Cr-Commit-Position: refs/heads/master@{#28735}

This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.

BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28731}

Also adapt code generation to pass the slot to the
store/keyed-store ic. AST nodes ObjectLiteral, Assignment,
ForEach, Call and CountOperation now include one or more
feedback vector ic slot ids.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28659}

When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:

  method() {
    var .home_object = %ThisFunction()[home_object_symbol];
    ...
  }

BUG=v8:3867, v8:4031
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28644}

This allows you to put iterables into your array literals
and the will get spread into the array.

  let x = [0, ...range(1, 3)];  // [0, 1, 2]

This is done by treating the array literal up to the first
spread element as usual, including using a boiler plate
array, and then appending the remaining expressions and rest
expressions.

BUG=v8:3018
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28534}

R=jochen@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27937}

This avoids both a mysterious boolean argument ("insert") and lets
non-mutating lookups skip passing an allocator (in one such case,
we were passing a scary-looking ZoneAllocationPolicy(NULL)!).

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

Cr-Commit-Position: refs/heads/master@{#27799}

These comparisons are only meant to be done by AstValueFactory itself (in
its string_table_ operations), so make the Compare() function a private
member of AstValueFactory.

All other clients of AstRawStrings should compare them by pointer value.
There were only two clients which failed to abide by this rule, one
recently-added (in ModuleDescriptor) and the other in Literal::Match
(in ast.cc, added in https://code.google.com/p/v8/source/detail?r=24396).

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

Cr-Commit-Position: refs/heads/master@{#27715}

A bug allows JSObject literals with elements to have the elements in the
boilerplate modified.

BUG=466993
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27511}

Remove Variable::IsValidReference(), and the Variable::is_valid_ref_
member: This was "false" only for "this", and for internal variables.
For the first, VariableProxy::is_this() can be used for the check
instead; and for internal variables, it is guaranteed they they will
not be written to (because the V8 code does not do it, and they are
not accessible from JavaScript).

The "bool is_this" parameter of VariableProxy() constructor is
changed to use Variable::Kind. This will allow to later on adding
a parameter to create unresolved variables of any kind, which in
turn will be used to make references to "this" initially unresolved,
and use the existing variable resolution mechanics for "this".

BUG=v8:2700
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27404}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27399}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27274}

We can reduce the number of type feedback vector slots required, and
also reduce IC misses.

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

Cr-Commit-Position: refs/heads/master@{#27149}

R=mvstanton@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#26890}

We cannot yet detect use-before-declaration in general, because for that we'd
need to analyze the context when compiling. But we can detect an error case
where we first see a use, then a declaration.

For this, I also added end position tracking (needed for error messages) to
VariableProxy.

Note: the position naming is completely inconsistent: start_position &
end_position, position & end_position, pos & end_pos, beg_pos & end_pos, to name
a few. This doesn't fix all of it, but tries to unify towards start_position &
end_position whenever possible w/ minimal changes.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#26880}

This gets Variable and VariableProxy out of the business of worrying about
Interfaces.

At the same time, get rid of the notion of "module variables". In ES6, variables
that refer to modules will be simply be CONST bindings to module namespace
objects.

The only change in logic here is one more early error:
duplicate export names are now rejected.

BUG=v8:1569
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#26708}

With the new ES6 semantics super construct calls are only valid in
a constructor in a derived class. This is something that is
statically known and we report early SyntaxError in case it occurs.
We therefore do not need to track this any more.

BUG=v8:3330
LOG=N
R=dslomov@chromium.org, adamk

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

Cr-Commit-Position: refs/heads/master@{#26644}

R=arv@chromium.org
BUG=v8:3834
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#26631}

This comment used to have a (commented-out) ASSERT attached to it.
But that ASSERT was removed years ago, so the comment is now a
non-sequitar.

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

Cr-Commit-Position: refs/heads/master@{#26587}

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26454}

We used to have a parse error for conflicting property keys. This check
was removed to match ES6 (SpiderMonkey & Chakra already made this change).
Since this check was removed we ended up with a few new cases when
generating code. For example, accessors always generated code even if
those should have been shadowed by a data property.

BUG=v8:3856
LOG=Y
R=adamk, dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26441}

This enables adding more language modes in the future.

For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.

For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.

LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#26419}

The Ast Call node is accustomed to using a vector IC slot for the
cases when it uses a CallIC. The super constructor work alters this
somewhat by using a CallConstructStub instead, however the
CallConstructStub expects a vector slot and not a vector ic slot.
This distinction needs to be maintained because slots and ic slots
have different clearing strategies and are handled differently.

R=dslomov@chromium.org
BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#26414}

This removes the duplicate property check from object literals.

Instead we repurpose the ObjectLiteralChecker into two cases, implemented
by two subclasses to ObjectLiteralCheckerBase called ObjectLiteralChecker
and ClassLiteralChecker.

The object literal checker now only checks for duplicate __proto__ fields in
object literals.

The class literal checker checks for duplicate constructors, non constructor
fields named constructor as well as static properties named prototype.

BUG=v8:3819
LOG=Y
R=adamk, dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26336}

It should be possible to create a concise method with the name
__proto__ without setting the [[Prototype]]. Similarly, property
name shorthands with the name __proto__ should define an own
property.

BUG=v8:3818
LOG=Y
R=adamk, dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26172}

This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.

This is a revert of the revert, 7d48fd9d.

BUG=v8:3754
LOG=Y
R=dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26084}

This also simplifies target_stack_ and tightens up the types of nodes
that can appear in it.

Best I can tell, this code has been dead since
https://code.google.com/p/v8/source/detail?r=7542

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

Cr-Commit-Position: refs/heads/master@{#26083}

Revert of ES6 computed property names (patchset #1 id:1 of https://codereview.chromium.org/792233008/)

Reason for revert:
[sheriff] Still crashes on win32 (XP):
http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%201/builds/1380

Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0.
>
> This changes to do an early bailout in
> HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
> loop.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.org

TBR=dslomov@chromium.org,arv@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754

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

Cr-Commit-Position: refs/heads/master@{#25872}

This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.

This is a revert of the revert, a76419f0.

This changes to do an early bailout in
HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
loop.

BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25868}

Revert of ES6 computed property names (patchset #1 id:1 of https://codereview.chromium.org/807173002/)

Reason for revert:
Crashes Win32. It was not flake.

Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0 with
> no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
> try again.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.org

TBR=dslomov@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754

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

Cr-Commit-Position: refs/heads/master@{#25853}

This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.

This is a revert of the revert, a76419f0 with
no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
try again.

BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25851}

Revert of ES6 computed property names (patchset #9 id:160001 of https://codereview.chromium.org/795573005/)

Reason for revert:
Crashes on Win32

http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%201/builds/1357

Test: mjsunit/harmony/computed-property-names
Flags: --stress-opt --always-opt
Command: build\Release\d8.exe --test --random-seed=-233815021 --stress-opt --always-opt --nohard-abort --nodead-code-elimination --nofold-constants --harmony-computed-property-names test\mjsunit\mjsunit.js test\mjsunit\harmony\computed-property-names.js

Run #1
Exit code: -1073741819
Result: CRASH
Expected outcomes: PASS

Run #2
Exit code: -1073741819
Result: CRASH
Expected outcomes: PASS

Run #3
Exit code: -1073741819
Result: CRASH
Expected outcomes: PASS

Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> BUG=v8:3754
> LOG=Y

TBR=dslomov@chromium.org,wingo@igalia.com
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754

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

Cr-Commit-Position: refs/heads/master@{#25825}

This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.

BUG=v8:3754
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#25821}

R=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25561}

R=rossberg@chromium.org,arv@chromium.org
BUG=v8:3330
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#25555}