Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
Cr-Commit-Position: refs/heads/master@{#32841}
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32857}
We used to flood the handler when preparing for stepping,
even if we may not throw. Instead, we now flood the
handler only when we actually throw.
This also solves an issue with step-next when we throw and
leave the function unexpectedly. In combination with
microtasks, this could cause a crash.
R=mstarzinger@chromium.org
BUG=chromium:568477
LOG=N
Review URL: https://codereview.chromium.org/1527593002
Cr-Commit-Position: refs/heads/master@{#32856}
Reason for revert:
[Sheriff] Layout test changes.
Original issue's description:
> [debugger] debug-evaluate should not not modify local values.
>
> Debug evaluate no longer writes back changes to the replicated
> context chain to the original after execution. Changes to the
> global object or script contexts still stick. Calling functions
> that bind to the original context chain also have their expected
> side effects.
>
> As far as I can tell, DevTools is not interested in modifying
> local variable values. Modifying global variable values still
> works as expected. However, I have not yet removed the old
> implementation, but merely keep it behind a flag.
>
> R=mstarzinger@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
> Cr-Commit-Position: refs/heads/master@{#32841}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1526553003
Cr-Commit-Position: refs/heads/master@{#32845}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32841}
There's at least one case of a time zone alias: Asia/Kathmandu aliases
Asia/Katmandu. ICU seems to normalize to the (deprecated) latter choice.
V8 internationalization choked on this change; this patch interprets
ICU's output more precisely and allows it.
BUG=chromium:487322
R=jungshik,adamk
LOG=Y
Review URL: https://codereview.chromium.org/1509273007
Cr-Commit-Position: refs/heads/master@{#32769}
Without this fix, AssignmentExpressions that happen to be arrow functions
would lead to unbalanced Enter/Leave calls on the fni_, causing thrashing
while trying to infer function names. Symptoms include slow parsing
or OOM (when we create too many AstConsStrings).
To try to keep this from happening in the future, added an RAII helper
class to handle Entering/Leaving FNI state.
The included regression test crashes on my workstation without the patch.
Note that it's too slow in debug mode (as well as under TurboFan),
so I've skipped it there.
BUG=v8:4595
LOG=y
Review URL: https://codereview.chromium.org/1507283003
Cr-Commit-Position: refs/heads/master@{#32768}
This is in preparation for turning the flag off by default.
BUG=chromium:552100
LOG=n
Review URL: https://codereview.chromium.org/1511293002
Cr-Commit-Position: refs/heads/master@{#32729}
- Add JSReceiver::SetIntegrityLevel, with a fast path for regular objects.
- Make Object.{freeze,seal} call this via %Object{Freeze,Seal}, thus no longer
using broken or deprecated functions from v8natives.js.
- Add JSReceiver::OwnPropertyKeys convenience function.
- Reenable harmony/proxies-hash.js test.
R=rossberg
BUG=v8:1543
LOG=N
Review URL: https://codereview.chromium.org/1489423002
Cr-Commit-Position: refs/heads/master@{#32651}
The backing store is only held alive indirectly via the array buffer
referenced by the holder (typed array), so it's not enough to keep the
elements alive (or even just the external pointer loaded from the
elements).
R=mstarzinger@chromium.org,bmeurer@chromium.org
LOG=n
BUG=v8:1827
Review URL: https://codereview.chromium.org/1493983004
Cr-Commit-Position: refs/heads/master@{#32644}
Reason for revert:
[Sheriff] Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3266
Please request rebase upstream first.
Original issue's description:
> Clean up promises and fix an edge case bug
>
> This patch builds on previous Promise spec compliance work by
> cleaning out some old code which existed to support
> Promise.prototype.chain, rephrasing some code to correspond more
> closely to the specification, and removing some incorrect brand
> checking. A test is added for a bug in an edge case which was fixed.
>
> R=rossberg
> BUG=v8:3641
> LOG=Y
>
> Committed: https://crrev.com/1deb89c8fd3cb69714ae0a24e3b5a4e78f6b73b4
> Cr-Commit-Position: refs/heads/master@{#32627}
TBR=rossberg@chromium.org,caitpotter88@gmail.com,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3641
Review URL: https://codereview.chromium.org/1501763004
Cr-Commit-Position: refs/heads/master@{#32629}
This patch builds on previous Promise spec compliance work by
cleaning out some old code which existed to support
Promise.prototype.chain, rephrasing some code to correspond more
closely to the specification, and removing some incorrect brand
checking. A test is added for a bug in an edge case which was fixed.
R=rossberg
BUG=v8:3641
LOG=Y
Review URL: https://codereview.chromium.org/1488783002
Cr-Commit-Position: refs/heads/master@{#32627}
Reason for revert:
Blocks the roll:
https://codereview.chromium.org/1497763004/
Original issue's description:
> [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors.
>
> The ArrayBuffer and SharedArrayBuffer constructors should raise an
> exception when called with no arguments or undefined length. Also
> unified the ArrayBuffer and SharedArrayBuffer implementations as C++
> builtins, and removed some (now) obsolete runtime entries.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
> Cr-Commit-Position: refs/heads/master@{#32590}
TBR=yangguo@chromium.org,cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1501673002
Cr-Commit-Position: refs/heads/master@{#32606}
The ArrayBuffer and SharedArrayBuffer constructors should raise an
exception when called with no arguments or undefined length. Also
unified the ArrayBuffer and SharedArrayBuffer implementations as C++
builtins, and removed some (now) obsolete runtime entries.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#32590}
non-constructors are not allowed to have initial maps. The optimizing compilers used to add initial maps unconditionally to functions used as right-hand-side in instanceof.
BUG=
Review URL: https://codereview.chromium.org/1490003003
Cr-Commit-Position: refs/heads/master@{#32497}
This fixes a corner-case in redeclaration handling, where the ES2015
early error case got mixed up with legacy const handling in the parser.
Redeclaration using ES2015 'let' and 'const' should be early errors,
but legacy 'const' redeclaration has historically been a runtime error,
and should stay that way until legacy 'const' is gone.
The fix here is uglier than it might be due to
https://code.google.com/p/v8/issues/detail?id=4577, which keeps us
from simplifying the mess of if/else-if in the current code.
BUG=v8:4576
LOG=n
Review URL: https://codereview.chromium.org/1485943002
Cr-Commit-Position: refs/heads/master@{#32429}
This replaces internal GetConstructorName with toStringTag, .constructor's name
and class_name. This entirely changes how the name is computed for use in
devtools.
BUG=chromium:529177
LOG=n
Review URL: https://codereview.chromium.org/1435273002
Cr-Commit-Position: refs/heads/master@{#32374}
We currently assume that all prototype maps are stable, which is
not guaranteed for certain keyed access patterns. So we explicitly
disallow optimizing the element access there for now.
BUG=chromium:557807, v8:4470
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1456973004
Cr-Commit-Position: refs/heads/master@{#32101}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
When adding properties to the result object, that object's prototype chain should be ignored.
Review URL: https://codereview.chromium.org/1458873002
Cr-Commit-Position: refs/heads/master@{#32085}
This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread
Review URL: https://codereview.chromium.org/1455953002
Cr-Commit-Position: refs/heads/master@{#32079}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1453733002
Cr-Commit-Position: refs/heads/master@{#32050}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1452193003
Cr-Commit-Position: refs/heads/master@{#32048}
