http://people.mozilla.org/~jorendorff/es6-draft.html#sec-set-object.prototype.__proto__

The __proto__ setter should be reusable on other objects.

BUG=v8:2804
LOG=y
R=rossberg@chromium.org

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

Patch from Erik Arvidsson <arv@chromium.org>.

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

BUG=
R=jkummerow@chromium.org, plind44@gmail.com

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

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

(I.e., move ReportUnexpectedToken to ParserBase.)

Because of the recent unifications, they now do the same thing.

BUG=
R=mstarzinger@chromium.org

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

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

BUG=338425
LOG=N
R=yangguo@chromium.org

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

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

Still relevant parts of the original commit message:

Unify paren handling in Parser and PreParser.

It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.

Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.

BUG=3126
LOG=N
R=ulan@chromium.org

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

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

R=dslomov@chromium.org

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

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

I have also cleaned up HOptimizedGraphBuilder::GenerateCallFunction
to use IfBuilder.

R=jkummerow@chromium.org
BUG=

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

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

R=hpayer@chromium.org

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

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

Ownership in this part is still very convoluted and should probably be
cleaned up, this is only the minimal CL needed to fix the leak.

R=yangguo@chromium.org

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

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

This reverts r19140.

Reason: Octane regression.

BUG=
TBR=verwaest@chromium.org

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

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

BUG=
R=mvstanton@chromium.org

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

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

R=verwaest@chromium.org

BUG=

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

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

BUG=
R=bmeurer@chromium.org

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

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

It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.

Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.

In addition, add helper funcs for checking if an Expression is identifier or a
given identifier. (PreParser Expressions can do this.)

BUG=3126
LOG=N
R=ulan@chromium.org

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

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

The exports_ hash map itself should live in the zone, too, not only
its entries.

R=rossberg@chromium.org

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

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

There's only one error message for "eval" and "arguments", so no need to pass it
to PreParser::StrictModeIdentifierViolation.

BUG=3126
LOG=N
R=ulan@chromium.org

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

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

R=hpayer@chromium.org

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

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

R=jkummerow@chromium.org
BUG=

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

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

R=verwaest@chromium.org

BUG=

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

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

Bumped an assembler buffer on the way, it is necessary for some combinations of debugging flags.

Note that the allocation profiler still leaks, this is handled in a separate CL.

R=bmeurer@chromium.org

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

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

R=yangguo@chromium.org, yurys@chromium.org

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

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

This resolves many mjsunit failures if long branches are forced to be emitted.

TEST=
BUG=
R=plind44@gmail.com

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

Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.

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

R=jkummerow@chromium.org
TBR=jkummerow@chromium.org

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

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

Port r19095 (caf48ad)

Original commit message:
Objects can actually be stored into themselves. This fails when no write
barrier is needed (eg, the object was just allocated).

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

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

The call to C++ function has to be done through t9 register for
the position independent code.

The crashes occur only for shared library build.

TEST=cctest/test-api/SetFunctionEntryHook
BUG=
R=plind44@gmail.com

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

Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.

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

Due to a different NaN representation on MIPS, the canonical nan
constant embedded in generated code that comes from snapshot will differ from
the one used on MIPS hardware.

TEST=mozilla/ecma/Array/15.4.4.2.js
BUG=
R=plind44@gmail.com

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

Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.

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

BUG=
R=danno@chromium.org

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

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

We used to have error messages which provide context, like "Variable name may
not be eval or arguments in strict mode", but for other illegal words we only
have non-context specific error messages like "Unexpected reserved word".

Providing the context makes the code unnecessarily complex, since every
individual place must remember to check for eval or arguments. This CL produces
a unified error message ("Unexpected eval or arguments in strict mode"), and puts
the error reporting to (Pre)Parser::ParseIdentifier.

Notes:

- The module feature is so experimental, that I decided to not allow "eval" or
"arguments" as module-related identifiers in the strict mode (even though this
check wasn't there before).

- Unfortunately, there were some inconsistencies, since it was the
responsibility of the caller of ParseIdentifier to check "eval" and "arguments"
and some places didn't have the check for no good reason. This CL is supposed to
keep backward compatibility and *not* introduce any new errors.

- ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax:
"LabelledStatement: Identifier : Statement", and no strict mode restrictions on
Identifier are listed.)

- Tests which compare error message strings will fail, and need to be updated.

BUG=3126
LOG=N
R=ulan@chromium.org

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

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

R=verwaest@chromium.org

BUG=

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

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

BUG=
R=dcarney@chromium.org

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

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

R=dcarney@chromium.org

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

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

We need a way to assert that for a given source code snippet, an error *is*
produced or *is not* produced. Otherwise we might accidentally create new
errors or start accepting code which was previously not accepted. Just checking
that Parser and PreParser produce the same result doesn't cut it.

BUG=3126
LOG=N
R=ulan@chromium.org

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

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

R=dcarney@chromium.org

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

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

R=verwaest@chromium.org

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

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

Check elimination improvement: propagation of state through phis is supported, CheckMap narrowing implemented.

R=titzer@chromium.org

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

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

If a function is marked or queued for concurrent compilation,
%OptimizeFunctionOnNextCall becomes a no-op. That can be wrong
if concurrent recompilation does not complete at the time we
expect the function to have been optimized.

R=hpayer@chromium.org

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

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

To avoid race with e.g. StackGuard::RequestInstallCode called from another
thread when both access postpone_interrupts_nesting_.

R=mvstanton@chromium.org
BUG=290964
LOG=N

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

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

Objects can actually be stored into themselves. This fails when no write
barrier is needed (eg, the object was just allocated).

R=bmeurer@chromium.org

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

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

R=ishell@chromium.org

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

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

This is what I think is a better solution to the "external strings in
old pointer space" problem. Basically, it is an issue because GC scans
all fields of objects in old pointer space and if the cached address
of the backing store is unaligned, it looks like a heap object, boom.

The solution here is to use short external strings when we externalize
a string in old pointer space, and when the address is unaligned.
Short external strings don't cache the address, so GC has no issues.

BUG=268686
LOG=Y
R=dcarney@chromium.org

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

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