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}
