The test demonstrates a bad interaction between arguments object
materialization, escape analysis and exception handling.
We can return a wrong arguments object if we materialize arguments
object (using f.arguments) and then throw around f's frame so that f
does not clean up the materialized frame information (see the
MaterializedObjectStore in deoptimizer.h/.cc). If we enter another
function that has the same frame pointer and request an arguments object
of (or lazily deoptimize) that function, we can get the materialized
object of the original function.
We should clean up the materialized object store when we unwind the
stack.
BUG=v8:3985
LOG=n
Review URL: https://codereview.chromium.org/1032623003
Cr-Commit-Position: refs/heads/master@{#27406}
The problem manifests itself when parsing manages to return something
meaningful in the presence of a stack overflow. This happens because
calling ParserBase::Next() will still return one valid token on stack
overflow, before starting to return invalid tokens.
Take the following input as example:
a.map(v => v + 1);
| |
already next token
parsed (which will be an invalid token
(identifier) because of a stack overflow)
The "v" may have been already parsed into a VariableProxy, then if a
stack overflow occurs, next token will be an invalid token (instead
of Token::ARROW), but the parser will return the VariableProxy.
This always happens when lazy-parsing arrow functions, so the position
in the input stream where the the arrow function code ends is known.
This fix adds a check that ensures that parsing ended at the end
position of the arrow function.
BUG=465671
LOG=N
Review URL: https://codereview.chromium.org/1023483003
Cr-Commit-Position: refs/heads/master@{#27325}
This ensures that there is only one stub that deals with unwinding the
stack. Having more than one place containing that logic is brittle and
error prone, especially when it is a corner case only for RangeErrors.
R=titzer@chromium.org
TEST=mjsunit/regress/regress-crbug-467047
BUG=chromium:467047
LOG=N
Review URL: https://codereview.chromium.org/1012103002
Cr-Commit-Position: refs/heads/master@{#27243}
The evaluation order of receiver versus arguments is not properly
defined by C++. This caused issues with Clang where the environment
changed after the receiveing environment was already loaded.
R=jarin@chromium.org
BUG=chromium:467531
TEST=mjsunit/regress/regress-crbug-467531
LOG=N
Review URL: https://codereview.chromium.org/1015683002
Cr-Commit-Position: refs/heads/master@{#27238}
ES6 specs the function length property (it was not part of ES5) and
it makes it configurable.
BUG=v8:3045
LOG=N
R=mstarzinger@chromium.org, adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/993073002
Cr-Commit-Position: refs/heads/master@{#27190}
This involved renaming apart a few more intrinsics. In the long run,
we want to clean up redundant intrinsics which just delegate.
BUG=v8:3947
LOG=n
Review URL: https://codereview.chromium.org/984963002
Cr-Commit-Position: refs/heads/master@{#27043}
Function name property is now standardized in ES6. It was a Mozilla proprietary
extension before. With ES6, the property was made configurable, so that it can
be used instead of another proprietary property, displayName.
This is a revert of revert c791d84112.
Last time this broke a Chrome browser test which has since been updated:
5f75a3be4c
BUG=v8:3333
LOG=N
R=mstarzinger@chromium.org,verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/977003004
Cr-Commit-Position: refs/heads/master@{#26996}
This is partially based on r21609 but that CL was incomplete.
Function name is still non writable so one has to use defineProperty
to change the actual value.
BUG=v8:3333
LOG=N
R=adamk, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/960343002
Cr-Commit-Position: refs/heads/master@{#26924}
It must always populate int32_value_, even if that's lossy, because other code (specifically, constant folding for truncating operations) relies on it.
BUG=v8:3865
LOG=y
Review URL: https://codereview.chromium.org/897263002
Cr-Commit-Position: refs/heads/master@{#26453}
Both SameValue and SameValueZero consider different NaNs equal, so we
better assign the same hash value to all NaNs.
BUG=v8:3859
LOG=y
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/897593002
Cr-Commit-Position: refs/heads/master@{#26391}
Arrow function parameter lists are parsed as expressions. When an identifier
is found a VariableProxy is created and added to the list of unresolved
variables for the scope. When parsing a function lazily, the scope has been
already resolved, so with this patch only the VariableProxy is created,
without adding it as an unresolved variable in the scope.
BUG=v8:3501
LOG=Y
Review URL: https://codereview.chromium.org/880253004
Cr-Commit-Position: refs/heads/master@{#26328}
The whole logic in DoMul makes me cry, so I made only the minimal
change to fix the issue...
BUG=v8:451322
LOG=y
Review URL: https://codereview.chromium.org/873703002
Cr-Commit-Position: refs/heads/master@{#26261}
