In Builtins::Generate_Construct, the system was trying to
call ConstructProxy on a Proxy object without a constructor
because it was checking the wrong bit in the Proxy object's
supported operation mask.
TEST=test262/built-ins/Proxy/create-target-is-not-constructor
BUG=
Review URL: https://codereview.chromium.org/1545983002
Cr-Commit-Position: refs/heads/master@{#33036}
port d3f074b231 (r33024)
original commit message:
We'll be able to optimize rest parameters in TurboFan similarly to the arguments array. This CL restores the previous behavior, and a follow-on will enable TurboFan optimization.
(TBR for rossberg since we discussed the revert beforehand. The only changes are a few lines related to tests and rebasing.)
BUG=
Review URL: https://codereview.chromium.org/1545053002
Cr-Commit-Position: refs/heads/master@{#33034}
atOrUndefined() will return undefined if the index is >= length()
BUG=
Review URL: https://codereview.chromium.org/1541413002
Cr-Commit-Position: refs/heads/master@{#33033}
We'll be able to optimize rest parameters in TurboFan similarly to the arguments array. This CL restores the previous behavior, and a follow-on will enable TurboFan optimization.
(TBR for rossberg since we discussed the revert beforehand. The only changes are a few lines related to tests and rebasing.)
TBR=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1537683002
Cr-Commit-Position: refs/heads/master@{#33024}
Essentially a revert of https://codereview.chromium.org/1346013005 but
preserving the refactorings in elements.cc which happened in the mean time.
drive-by-fix: pass isolate as argument to more functions in elements.cc.
BUG=v8:4606
LOG=y
Review URL: https://codereview.chromium.org/1543563002
Cr-Commit-Position: refs/heads/master@{#33023}
Changes LoadGlobal, StoreGlobal, LoadNamedProperty, and StoreNamedProperty to accept
the name of variable instead of index into the constant pool entry. Also made
GetConstantPoolEntry as a private function since it is no longer used outside of
BytecodeArrayBuilder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1546643002
Cr-Commit-Position: refs/heads/master@{#33020}
Adds support for deleting a variable in a lookup slot. Adds a new bytecode,
its implementation and tests. Also adds support for this bytecode to the
bytecode graph builder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1542083002
Cr-Commit-Position: refs/heads/master@{#33019}
port 4acca53e62cdfe6f3c495c87ca7d3c8fe1059f01(r32996)
original commit message:
There's actually no point trying to do Function.prototype.toString in
JavaScript, as it always calls into C++ at least once, so it only
complicates things (esp. once we start optimizing bound functions).
Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
reflect the fact that these are builtins in the Function.prototype and
not on Function itself.
BUG=
Review URL: https://codereview.chromium.org/1548483003
Cr-Commit-Position: refs/heads/master@{#33017}
I believe the code reads easier after this change. The original code
probably dates back to when we had 4 gap positions. Now that there
are only 2, the logic can be simpler by avoiding a loop and instead
treating each case explicitly: no gaps; gaps just at end; gaps at start and
maybe end. That way, it is also easier to understand how the moves get
pushed downwards. This is what got me to make this change in the first
place: trying to work out a finer grained move optimization.
BUG=
Review URL: https://codereview.chromium.org/1543973002
Cr-Commit-Position: refs/heads/master@{#33016}
Port 4acca53e62
Original commit message:
There's actually no point trying to do Function.prototype.toString in
JavaScript, as it always calls into C++ at least once, so it only
complicates things (esp. once we start optimizing bound functions).
Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
reflect the fact that these are builtins in the Function.prototype and
not on Function itself.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1544833002
Cr-Commit-Position: refs/heads/master@{#33014}
Add API-accessors for [[ProxyTarget]], [[ProxyHandler]]. Additionally
create new proxies and revoke proxies via the API.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1542943002
Cr-Commit-Position: refs/heads/master@{#33013}
These constructors always go through C++ at least twice anyway, so
there's not really a point in trying to implement them in JavaScript.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1548623002
Cr-Commit-Position: refs/heads/master@{#33012}
Function proxies would not be printed so far since they ended up in Function.prototype.toString which only works with Function as a receiver but no Proxy. Additionally added support for more gracefully dealing with recursive __proto__ structures introduced by proxies.
drive-by-fix: use IS_PROXY if possible in .js files.
BUG=v8:1543
LOG=n
Committed: https://crrev.com/8bfb7189a3472bc9d0820a1bd4534eaaf78ff847
Cr-Commit-Position: refs/heads/master@{#32985}
Review URL: https://codereview.chromium.org/1530293004
Cr-Commit-Position: refs/heads/master@{#33010}
Creating proto-recursive proxies might lead to instanceof while-looping
endlessly in Object::HasInPrototypeChain (For traps we already have stack
guards in place to prevent stack overflows). We prevent this by limiting
the number of proxies we visit in PrototypeIterator to a magic large number.
LOG=n
BUG=v8:1534
Review URL: https://codereview.chromium.org/1542583003
Cr-Commit-Position: refs/heads/master@{#33007}
The GlobalEval JavaScript function was just a small driver for stuff
implemented in C++ anyway, so there's no point in having it around at
all. The next step will be to move the Function constructor to C++ as
well, which is the other user of %CompileString.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1540893004
Cr-Commit-Position: refs/heads/master@{#33006}
Consecutive registers are allocated in two passes. First we "reserve"
a set of registers and these get allocated when we actually use them.
If we request for a temporary register before we use all the consecutive
registers, the earlier implementation does not gaurantee that it allocates
outside the reservation for consecutive registers. This could cause problems
for example, in call_func(a, b++, c). This cl fixes
TemporaryRegisterScope::NewRegister, to return a new temporary register
outside the reservation for consecutive registers.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1531273002
Cr-Commit-Position: refs/heads/master@{#33005}
Adds implementation and tests for CreateMappedArguments and
CreateUnmappedArguments to bytecode graph builder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1490283003
Cr-Commit-Position: refs/heads/master@{#33004}
Unexpectedly, websites depend on doing feature testing with
RegExp.prototype.sticky and browser testing with RegExp.prototype.toString().
ES2015 newly throws exceptions for both of these. In order to enable shipping
new ES2015 semantics, this patch puts in narrow workarounds for those two
cases, keeping their old behavior. UseCounters are added for how often
those particular cases come up, so we can see if it can be deprecated.
This reland replaces problematic legacy const usage with var, to
avoid issues with nosnap builds.
R=yangguo
CC=bmeurer
BUG=v8:4637,v8:4617
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1545633002
Cr-Commit-Position: refs/heads/master@{#33002}
Reason for revert:
needs --allow-natives-syntax
Original issue's description:
> [proxies] Better print for proxies in d8
>
> Function proxies would not be printed so far since they ended up in Function.prototype.toString which only works with Function as a receiver but no Proxy. Additionally added support for more gracefully dealing with recursive __proto__ structures introduced by proxies.
>
> BUG=v8:1543
> LOG=n
>
> Committed: https://crrev.com/8bfb7189a3472bc9d0820a1bd4534eaaf78ff847
> Cr-Commit-Position: refs/heads/master@{#32985}
TBR=neis@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1543
Review URL: https://codereview.chromium.org/1543803002
Cr-Commit-Position: refs/heads/master@{#33001}
Reason for revert:
Breaks nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/5883
Original issue's description:
> Add web compat workarounds for ES2015 RegExp semantics
>
> Unexpectedly, websites depend on doing feature testing with
> RegExp.prototype.sticky and browser testing with RegExp.prototype.toString().
> ES2015 newly throws exceptions for both of these. In order to enable shipping
> new ES2015 semantics, this patch puts in narrow workarounds for those two
> cases, keeping their old behavior. UseCounters are added for how often
> those particular cases come up, so we can see if it can be deprecated.
>
> R=yangguo
> BUG=v8:4637,v8:4617
> LOG=Y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52
> Cr-Commit-Position: refs/heads/master@{#32997}
TBR=yangguo@google.com,yangguo@chromium.org,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4637,v8:4617
Review URL: https://codereview.chromium.org/1546493003
Cr-Commit-Position: refs/heads/master@{#32999}
There was no use for the second temp vector, and the one we
are using is scoped to certain methods, and that scope can be
further restricted.
I'm curious if there is really any value in having the temp
vector instead of allocating a function-scoped local. Will
verify that separately.
Review URL: https://codereview.chromium.org/1533423003
Cr-Commit-Position: refs/heads/master@{#32998}
Unexpectedly, websites depend on doing feature testing with
RegExp.prototype.sticky and browser testing with RegExp.prototype.toString().
ES2015 newly throws exceptions for both of these. In order to enable shipping
new ES2015 semantics, this patch puts in narrow workarounds for those two
cases, keeping their old behavior. UseCounters are added for how often
those particular cases come up, so we can see if it can be deprecated.
R=yangguo
BUG=v8:4637,v8:4617
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1543723002
Cr-Commit-Position: refs/heads/master@{#32997}
There's actually no point trying to do Function.prototype.toString in
JavaScript, as it always calls into C++ at least once, so it only
complicates things (esp. once we start optimizing bound functions).
Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
reflect the fact that these are builtins in the Function.prototype and
not on Function itself.
TBR=hpayer@chromium.orgR=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1540953004
Cr-Commit-Position: refs/heads/master@{#32996}
The trunc_l_[s,d] instructions incorrectly returns success when the input is INT64_MAX.
TEST=test-run-machops/RunTryTruncateFloat32ToInt64WithCheck,test-run-machops/RunTryTruncateFloat64ToInt64WithCheck
BUG=
Review URL: https://codereview.chromium.org/1542673002
Cr-Commit-Position: refs/heads/master@{#32990}
The CL #32908 (https://codereview.chromium.org/1526293002) updated the Float64 test data and cause the RunFloat64Add and RunFloat64Sub test cases failed.
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/
Here is the key comments from CL #31808
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
So we add the following sentence to do type case to keep the same precision for RunFloat64Add and RunFloat64Sub.
Such as: volatile double expect = *i +/- *j; // *i +/- *j, etc.
BUG=
Review URL: https://codereview.chromium.org/1533593003
Cr-Commit-Position: refs/heads/master@{#32988}
