Also fix Debug.showBreakPoints for multiple break points at the same location.
BUG=v8:3960
LOG=N
Review URL: https://codereview.chromium.org/998253005
Cr-Commit-Position: refs/heads/master@{#27444}
This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.
Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).
On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).
R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry
Review URL: https://codereview.chromium.org/1010883002
Cr-Commit-Position: refs/heads/master@{#27440}
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}
Also fix mjsunit/regress/regress-undefined-nan to ensure that we are
testing transfer via xmm registers by forcing the transfer to be in an
optimized function.
BUG=v8:3839
LOG=n
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/863153002
Cr-Commit-Position: refs/heads/master@{#26213}
This time we simply undo the change introduced by the PPC port for
this test. No idea why it should be necessary, and Windows XP
obviously doesn't give us that much stack, anyway.
TBR=machenbach@chromium.org
Review URL: https://codereview.chromium.org/826833003
Cr-Commit-Position: refs/heads/master@{#26093}
The test fails on XP only, so let's tentatively raise the stack limit more. We probably need to investigate what a tighter limit might be and (more importantly) what the underlying reason for the failure is.
Hopefully 1800kB is enough, we can't test this via try jobs, because we don't have XP try bots. :-/
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/791693005
Cr-Commit-Position: refs/heads/master@{#26092}
The bug would occur when we try to Reset() to a position already at the end.
This happens e.g., when the regexp ends with \u. What used to happen in that
case: 1) Advance past \ and u (to the end) (which wouldn't increase next_pos_
enough) 2) Try to parse 4 hex digits 3) When that failed, Reset() to the
position which should've been at the end but wasn't.
To be able to properly Reset() to a position at the end, we need to allow
next_pos_ to move beyond the end (since position() is next_pos_ - 1).
Minimal repro case:
var r = /foo\u/
r.test("foou") // should be true, was false.
(Note that \u not followed by 4 hex didits should be interpreted as an identity
escape. It already worked unless \u was at the end of the regexp.)
BUG=v8:3756
LOG=NO
Review URL: https://codereview.chromium.org/802313003
Cr-Commit-Position: refs/heads/master@{#25838}
The %OptimizeFunctionOnNextCall sledgehammer can cause a function to be
marked for optimization before it's ever been compiled by fullcode.
This can lead to the situation where a function doesn't have optimization
disabled until we try to compile it optimized.
Basically, the assert should just handle this case more gracefully.
R=yangguo@chromium.org
BUG=436893
LOG=Y
Review URL: https://codereview.chromium.org/760063002
Cr-Commit-Position: refs/heads/master@{#25528}
Per TC39 Nov 2014 decision.
This patch also changes behavior for "legacy const": assignments to sloppy const in strict mode is now also a type error. This fixes v8:2243 and also brings us in compliance with other engines re assignment to function names (see updated webkit test), but might have bigger implications.
That change can easily be reverted by changing Variable::IsSignallingAssignmentToConst.
BUG=v8:3713,v8:2243
LOG=N
Review URL: https://codereview.chromium.org/749633002
Cr-Commit-Position: refs/heads/master@{#25516}
Resets the scaled exponent to 0 when the scaling match fails.
BUG=
Review URL: https://codereview.chromium.org/756643002
Cr-Commit-Position: refs/heads/master@{#25491}
The bug was an error when copying arrays in crankshaft. If it's a holey smi
array, the copy must be done as FAST_HOLEY_ELEMENTS to prevent representation
changes from being inserted that deopt on encountering the hole.
Also, prevent inlining array pop() and shift() if the length is read-only.
BUG=435073
LOG=N
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/737383002
Cr-Commit-Position: refs/heads/master@{#25455}
if there is not enough type-feedback to detect that f is Function.prototype.apply.
BUG=v8:3709
LOG=N
TEST=mjsunit/regress/regress-3709
Review URL: https://codereview.chromium.org/736043002
Cr-Commit-Position: refs/heads/master@{#25447}
With Int32Add we lose the int/uint distinction, so later, in simplified lowering we can make a wrong decision. E.g., see the attached test case, where we lower NumberAdd -> Int32Add because inputs are Uint32, but during simplified lowering we change the inputs to Int32, so we get a wrong result.
Simplified lowering will lower the NumberAdd operations anyway, so we should lose performance.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/721723004
Cr-Commit-Position: refs/heads/master@{#25368}
Revert "Fix for an assertion failure in Map::FindTransitionToField(...). Appeared after r25136."
This revert is made in order to revert r25099 which potentially causes renderer hangs.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/722873004
Cr-Commit-Position: refs/heads/master@{#25332}
