Attempt #<really big number>
Parses, and lazily rewrites Destructuring Assignment expressions. The rewriting strategy involves inserting a placeholder RewritableAssignmentExpression into the AST, whose content expression can be completely rewritten at a later time.
Lazy rewriting ensures that errors do not occur due to eagerly rewriting nodes which form part of a binding pattern, thus breaking the meaning of the pattern --- or by eagerly rewriting ambiguous constructs that are not immediately known
BUG=v8:811
LOG=Y
R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1309813007
Cr-Commit-Position: refs/heads/master@{#32623}
On some architectures the InvokeBuiltin sequence does not go through
InvokeFunctionCode, which initializes the new.target register. This
initializes the register explicitly on these architectures for now.
R=ishell@chromium.org
BUG=chromium:565046
LOG=n
Review URL: https://codereview.chromium.org/1499953002
Cr-Commit-Position: refs/heads/master@{#32622}
Having beefed up GetKeys() to support everything, use it for everything now.
This fixes Object.getOwnPropertyNames and Object.getOwnPropertySymbols for
Proxies, and gets rid of a bunch of code duplication.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1498593006
Cr-Commit-Position: refs/heads/master@{#32620}
Fixing warnings which cause compilation to fail when compiling
using CLANG for MIPS
BUG=
Review URL: https://codereview.chromium.org/1493793002
Cr-Commit-Position: refs/heads/master@{#32619}
Create a visitor for evacuating objects for young and old generation. This is
the first step of preparing a task to process, both, newspace and oldspace
pages in parallel.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1499893002
Cr-Commit-Position: refs/heads/master@{#32617}
Fix the missed store buffer entries for live objects on aborted pages. Marking
the page as scan_on_scavenge takes care of rebuilding the entries. Note that
this requires an additional case in the rebuilding logic as we cannot iterate an
aborted pages using the object layout, but rather have to use mark bits for
this.
BUG=chromium:524425, chromium:564498
LOG=N
Review URL: https://codereview.chromium.org/1497883003
Cr-Commit-Position: refs/heads/master@{#32610}
For now, we revoke a proxy by setting its handler to null (as in the spec).
Change the "target" field from Object to JSReceiver as there's no point in
allowing more.
R=jkummerow@chromium.org, rossberg
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1496243003
Cr-Commit-Position: refs/heads/master@{#32608}
Reason for revert:
Blocks the roll:
https://codereview.chromium.org/1497763004/
Original issue's description:
> [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors.
>
> The ArrayBuffer and SharedArrayBuffer constructors should raise an
> exception when called with no arguments or undefined length. Also
> unified the ArrayBuffer and SharedArrayBuffer implementations as C++
> builtins, and removed some (now) obsolete runtime entries.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
> Cr-Commit-Position: refs/heads/master@{#32590}
TBR=yangguo@chromium.org,cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1501673002
Cr-Commit-Position: refs/heads/master@{#32606}
Reason for revert:
Blocks the roll:
https://codereview.chromium.org/1497763004/
Original issue's description:
> [es6] Match ArrayBuffer constructor behavior of Firefox.
>
> We choose to deliberately violate the ES2015 specification and implement
> the ArrayBuffer constructor in a way that matches Firefox and Safari
> instead.
>
> BUG=v8:4592
> LOG=n
>
> Committed: https://crrev.com/8aae841ce26f01f3535e54af3a58fb7c65833eb7
> Cr-Commit-Position: refs/heads/master@{#32597}
TBR=jarin@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4592
Review URL: https://codereview.chromium.org/1496293002
Cr-Commit-Position: refs/heads/master@{#32605}
Reason for revert:
Seems to be (mostly) responsible for the most recent Speedometer regression, not 100% sure. Let's see what the bots have to say.
Original issue's description:
> Provide call counts for constructor calls, surface them as a vector IC.
>
> CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there is a request to make CallConstructStub look analogous. Enter ConstructICStub.
>
> BUG=
>
> Committed: https://crrev.com/66d5a9df62da458a51e8c7ed1811dc9660f4f418
> Cr-Commit-Position: refs/heads/master@{#32452}
TBR=mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1489413006
Cr-Commit-Position: refs/heads/master@{#32599}
We choose to deliberately violate the ES2015 specification and implement
the ArrayBuffer constructor in a way that matches Firefox and Safari
instead.
BUG=v8:4592
LOG=n
Review URL: https://codereview.chromium.org/1497163002
Cr-Commit-Position: refs/heads/master@{#32597}
The expression Number(x) is essentially equivalent to ToNumber(x),
so just lower to JSToNumber in the JSCallReducer and let typing
and typed lowering take care of optimizations.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1497903002
Cr-Commit-Position: refs/heads/master@{#32596}
port 57117b8339 (r32308)
original commit message:
The Float32RoundTiesEven operator rounds float32 numbers towards the nearest
integer. If the distance to two integers is the same, then the result is
the even integer. This is the default rounding mode of the ieee 754 floating
point standard.
I implemented the optional Float32RoundTiesEven operator on x64, ia32, arm, and arm64.
BUG=
Review URL: https://codereview.chromium.org/1492293002
Cr-Commit-Position: refs/heads/master@{#32595}
port a330af0ed1 (r32539)
original commit message:
The optimized code generated by Crankshaft cannot properly deal
with proxies (in the prototype chain), and there's probably no
point in trying to make that work^Wfast with Crankshaft at all.
TurboFan will handle that properly; Crankshaft just bails out
to fullcodegen, which then goes to the runtime, which should do
the right thing soon.
BUG=
Review URL: https://codereview.chromium.org/1495803003
Cr-Commit-Position: refs/heads/master@{#32594}
Rolling v8/buildtools to b747a9e091cb8212a62343258406eaf53a6c032e
Rolling v8/tools/clang to 58b11d197b1c5fec39a6ec374c21b3d3a5bf557b
Rolling v8/tools/swarming_client to 9cdd76171e517a430a72dcd7d66ade67e109aa00
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1493273004
Cr-Commit-Position: refs/heads/master@{#32593}
The ArrayBuffer and SharedArrayBuffer constructors should raise an
exception when called with no arguments or undefined length. Also
unified the ArrayBuffer and SharedArrayBuffer implementations as C++
builtins, and removed some (now) obsolete runtime entries.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#32590}
Port a330af0ed1
Original commit message:
The optimized code generated by Crankshaft cannot properly deal
with proxies (in the prototype chain), and there's probably no
point in trying to make that work^Wfast with Crankshaft at all.
TurboFan will handle that properly; Crankshaft just bails out
to fullcodegen, which then goes to the runtime, which should do
the right thing soon.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1496843004
Cr-Commit-Position: refs/heads/master@{#32583}
Fix several operations in the parser that rewrite constant expressions
to preserve knowledge regarding whether a value originally contained a ".".
This information is required to accurately validate Asm.js typing.
Making the assumption that if either side of a binary operation contains
a dot, that the rewritten expression should be treated as a double for
Asm.js purposes. This is a slight deviation from the spec (which
would forbid mix type operations).
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator, test-parsing
R=titzer@chromium.org,marja@chromium.org,aseemgarg@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1492123002
Cr-Commit-Position: refs/heads/master@{#32581}
I added a flag to the CallDescriptor which indicates that the native
stack should be used for a CallObject instead of the js stack on arm64.
Additionally I removed the use of EmitPrepareArguments because the
current implementation does not work when float and int parameters are
mixed. I plan to fix it in a future CL, because currently I have a
problem figuring out the type of a parameter.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1494123002
Cr-Commit-Position: refs/heads/master@{#32577}
