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}
This relands commit ea74f0f85a.
The revert was due to failures in cctest/test-heap/ReleaseOverReservedPages,
caused by apparent changes to memory layout and fragmentation of the
first page. Eliminating a situation in messages.js where this CL has had
an effect on map transitions seems to solve the issue.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/714883003
Cr-Commit-Position: refs/heads/master@{#25266}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The spec explicitly forbids them. V8 never handled them properly either, just
the Scanner accepted them (it had code to add them literally to the
LiteralBuffer) and later on, Regexp constructor disallowed them.
According to the spec, unicode escapes in regexp flags should be an early error
("It is a Syntax Error if IdentifierPart contains a Unicode escape sequence.").
Note that Scanner is still more relaxed about regexp flags than the
spec. Especially, it accepts any identifier parts (not just a small set of
letters) and doesn't check for duplicates.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/700373003
Cr-Commit-Position: refs/heads/master@{#25215}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
