Import Blink layout tests for Promises.
We omitted some tests (for example workers tests).
We fixed some wrong test expectations.

BUG=347095
LOG=N
R=rossberg@chromium.org

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

Patch from Yutaka Hirano <yhirano@chromium.org>.

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

BUG=
R=mvstanton@chromium.org

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

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

This fixes two issues:
- Update externalize-string-extension to the behavior of the API (see r18285)
- Convert cons strings in old pointer space to short external strings as
  expected by Heap::AllowedToBeMigrated, regardless of alignment.

R=mstarzinger@chromium.org

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

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

Promise.all and Promise.race should reject the returned Promise if an
invalid parameter is given.
Since they don't support iterable now, they should reject the Promise
if a non-array parameter is given.

BUG=347453
LOG=Y
R=rossberg@chromium.org

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

Patch from Yutaka Hirano <yhirano@chromium.org>.

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

The tests were using different kind of constructs for achieving the same
thing. This makes refactoring the compilation API more difficult than it should
be.

cctest.h already contained helpers for compiling and running scripts, but they
were not used consistently.

For example, all these were used for running scripts:

v8::Script::Compile(v8_str("foo"))->Run();
v8::Script::Compile(v8::String::NewFromUtf8(isolate, "foo))->Run();
CompileRun(v8_str("foo"));
CompileRun(v8::String::NewFromUtf8(some_way_to_get_isolate(), "foo"));
v8::Local<v8::Script> script = any_of_the_above; script->Run();

Most of the tests just want to run a script (which is in const char*) and don't
care about how the v8::String is constructed or passed to the compiler API. Using
the helpers makes the test more readable and reduces boilerplate code which is
unrelated to what the test is testing.

R=dcarney@chromium.org
BUG=

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

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

As specified, they should unwrap resolution values recursively.

BUG=347427
LOG=Y
R=rossberg@chromium.org

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

Patch from Yutaka Hirano <yhirano@chromium.org>.

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

It is not safe to access the range for an SSA value
after range analysis.

BUG=v8:3204
LOG=y
R=svenpanne@chromium.org

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

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

Notes:
- The regexp in the ParseObjectLiteralComment was wrong, made it less wrong (
it's still wrong since trailing commas are not required / allowed).
- Change in logic: In case we have "get somekeyword() { }", the "somekeyword"
was not logged as a symbol by PreParser and not expected in the preparser data
by Parser. This is unnecessary complication; in other contexts where keywords
are allowed as identifiers, they are logged as symbols (see
ParseIdentifierName).

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

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

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

Fixed the flooring div bug and added a test case.

R=svenpanne@chromium.org

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

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

R=dslomov@chromium.org
TBR=dslomov@chromium.org

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

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

Contributed by fmeawad@chromium.org

R=yangguo@chromium.org

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

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

R=verwaest@chromium.org

BUG=

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

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

Also use temporary wrapper functions where possible to mark progress.

R=ishell@chromium.org

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

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

R=jarin@chromium.org

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

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

R=rossberg@chromium.org

BUG=

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

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

Allow Object::InternalFieldCount and Object::GetAlignedPointerFromInternalField to be called from Persistent classes

R=svenpanne@chromium.org

BUG=

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

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

Goto does not emit a jump if the target is the next emitted block.
However, if there is an unreachable block between Goto and the jump
target, we still emit a jump even though the unreachable block is
not actually emitted. That jump is unnecessary.

R=jkummerow@chromium.org

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

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

R=jarin@chromium.org

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

Patch from Cosmin Truta <ctruta@gmail.com>.

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

Also refactor the related code in preparation for fixing the
range analysis.

BUG=v8:3204
LOG=y
R=svenpanne@chromium.org

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

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

Original Issue: https://codereview.chromium.org/183683022/

TBR=rossberg
BUG=v8:2409
LOG=Y

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

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

TBR=rossberg
BUG=

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

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

R=rossberg@chromium.org, rossberg
BUG=v8:2409
LOG=Y

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

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

Port r19715 (0d6d244)

Original commit message:
Lithium currently supports 3 division-like operations on integral
operands: "Normal" division (rounding towards zero), flooring division
(rounding towards -Infinity) and modulus calculation (the counterpart
for the "normal" division). For divisors which are a power of 2, one can
efficiently use some bit fiddling to avoid the actual division for such
operations. This CL cleanly splits off these operations into separate
Lithium instructions, making the code much more maintainable and more
consistent across platforms.

There are 2 basic variations of these bit fiddling algorithms: One
involving branches and a seemingly more clever one without branches.
Choosing between the two is not as easy as it seems: Benchmarks (and
probably real-world) programs seem to favor positive dividends,
registers and shifting units are sometimes scarce resources, and branch
prediction is quite good in modern processors. Therefore only the
"normal" division by a power of 2 is implemented in a branch-free
manner, this seems to be the best approach in practice. If this turns
out to be wrong, we can easily and locally change this.

BUG=
R=plind44@gmail.com

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

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

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

Port r19704 (120500a)

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

BUG=
R=plind44@gmail.com

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

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

BUG=None
LOG=N
TBR=mstarzinger@chromium.org

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

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

BUG=
R=ulan@chromium.org

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

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

BUG=None
TBR=mstarzinger@chromium.org

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

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

AllocationTracker now maintains a map from address range to stack trace that allocated the range. When snapshot is generated the map is used to find construction stack trace for an object using its address.

BUG=chromium:277984
LOG=Y
R=alph@chromium.org, mstarzinger@chromium.org

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

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

R=ulan@chromium.org

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

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

Port r19706 (81fd8dd)

Original commit message:
We can make more efficient code to check against type cells in the future if we use symbols, guaranteed not to conflict with user code. Currently, the "symbols" are the hole and undefined. Undefined may come in from the outside.

BUG=
R=mvstanton@chromium.org

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

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

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

This patch:
 - uses named registers
 - reserves all the stack space in one go to avoid operations on csp
 - uses LDP/STP to copy the arguments

R=jochen@chromium.org

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

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

Notes about a few TODOs handled in this patch:

* In ProfileEntryHookStub::Generate:
    Stubs are always called with relocation.

* In CreateArrayDispatchOneArgument:
    The branches to registers can't be conditional. We could use a jump table, but
    there are only 6 different kinds so it is likely not worth it.

* In Builtins::Generate_StringConstructCode:
    Rename the argc register (x0) after its meaning changes.
    Remove a TODO: using a macro would not make the code clearer.

* In Generate_JSEntryTrampolineHelper:
    Remove the TODO and raise an internal issue to investigate this.

* In Disassembler::SubstituteBranchTargetField:
    Print the target address, but we don't have more info on the target.

R=ulan@chromium.org

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

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

This relands r19704 with a fix to the test case.

R=svenpanne@chromium.org

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

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

Revert "Handle non-power-of-2 divisors in division-like operations", "A64 tweaks for division-like operations." and "Windows build fix.".

This reverts commit 19719, 19720 and 19721 because
mozilla/ecma/Date/15.9.3.1-1 fails (in release mode only?).

TBR=bmeurer@chromium.org

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

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

TBR=ulan@chromium.org

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

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

R=bmeurer@chromium.org

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

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

R=bmeurer@chromium.org

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

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

When object is creating via native V8 API calls JS callstack is empty and the allocation is indistinguishable from say compiler allocations. This change adds a separate entry for such allocations.

Since FunctionInfo not necessarily corresponds to a heap object they are now referred to using their index in the list of all FunctionInfos.

BUG=chromium:277984
LOG=N
R=loislo@chromium.org, mstarzinger@chromium.org

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

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

This will reduce heavy ScopeIterator instantiations.
Once incorporated into chromium, will give 30% speed boost.

BUG=chromium:340285
LOG=Y
R=ulan@chromium.org, Yang, rossberg, ulan

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

Patch from Andrey Adaykin <aandrey@chromium.org>.

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

The new test didn't recognize that non-sse2 builds on ia32 would
disable crankshaft.

R=yangguo@chromium.org

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

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