A statement could have several break positions. The entire statement
should be considered muted if break points across all these break
positions evaluate to false.
R=verwaest@chromium.org
BUG=chromium:429167
LOG=N
Review URL: https://codereview.chromium.org/1615903002
Cr-Commit-Position: refs/heads/master@{#33522}
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}
TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1632993003
Cr-Commit-Position: refs/heads/master@{#33520}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1563213002
Cr-Commit-Position: refs/heads/master@{#33518}
This increases the size of register operands to be 16-bit.
Not all bytecodes have wide register variants, so when they are
needed a register translator will copy them into a small area
reserved at the top of the 8-bit register range and these registers
are supplied as arguments to the bytecode with 8-bit operands.
This is non-intrusive for typical bytecode where the number of
registers is less than 120. For bytecodes with wide register
operands (above the window) their index needs to be translated
to avoid the reserved translation window.
Enables splay.js to run in Octane and a handful of mjsunit tests.
BUG=v8:4280,v8:4675
LOG=NO
Review URL: https://codereview.chromium.org/1613163002
Cr-Commit-Position: refs/heads/master@{#33516}
Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
and use it as the return address when building interpreter frames during deopt.
This ensures that we restart execution of the outer frame at the correct
bytecode.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1633633002
Cr-Commit-Position: refs/heads/master@{#33512}
Adds support for calling native function literals. Moves the logic for building
the native function's SharedFunctionInfo out of full-codegen into compiler.cc
to allow it to be shared between fullcodegen and Ignition.
BUG=v8:4686
LOG=N
Review URL: https://codereview.chromium.org/1635553002
Cr-Commit-Position: refs/heads/master@{#33510}
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.
Tail calling can be enabled by --harmony-tailcalls flag.
BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1609893003
Cr-Commit-Position: refs/heads/master@{#33509}
SpiderMonkey switched to 2, test262 tests for 2, and 2 is a reasonable, natural
value.
R=yangguo
Review URL: https://codereview.chromium.org/1616233002
Cr-Commit-Position: refs/heads/master@{#33504}
This patch makes Array.prototype.concat support subclassing Arrays
and constructing instances properly with Symbol.species. It is
guarded by the --harmony-species flag.
R=cbruni
LOG=Y
BUG=v8:4093
Review URL: https://codereview.chromium.org/1577043002
Cr-Commit-Position: refs/heads/master@{#33503}
This patch is a workaround to the performance regression caused by
implementing the ES2015 TypedArray prototype chain: Include a
per-TypedArray-subclass length getter so that the superclass getter does
not become polymorphic. The patch appears to fix a regression in the
Gameboy Octane benchmark.
BUG=chromium:579905
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1624383003
Cr-Commit-Position: refs/heads/master@{#33501}
This fixes corner cases where the start offsets of exception handler
regions within the handler table fall together. This assumption was
based on full-codegen code and no longer holds with the interpreter.
The tables however are still well nested and code has been added to
verify that in debug mode.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1633573002
Cr-Commit-Position: refs/heads/master@{#33495}
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1631593003
Cr-Commit-Position: refs/heads/master@{#33494}
Cleanup %ForInPrepare runtime entry, and unify common logic with
%ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
a TupleType to properly type JSForInPrepare and its projections w/o
special hacks in the Typer. And fix %ForInNext and JSForInNext to be
consistent with fullcodegen again (after the proxy refactorings last
quarter).
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1631583002
Cr-Commit-Position: refs/heads/master@{#33487}
The web appears to depend on being able to redeclare functions-in-blocks
in sloppy mode (examples seen so far tend to redeclare identical functions,
most likely accidentally).
This patch opens a minimal hole: two same-named function declarations
in the same scope are allowed, only in sloppy mode.
BUG=v8:4693, chromium:579395
LOG=y
Review URL: https://codereview.chromium.org/1622723003
Cr-Commit-Position: refs/heads/master@{#33478}
Change the interpreter to always store the current context in the frame's
context slot instead of the function context. This makes it possible to
restore the correct context during deopt.
BUG=v8:4678,v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1604923002
Cr-Commit-Position: refs/heads/master@{#33477}
These tests have been disabled while support for try-finally was work in
progress. By now control flow is connected properly and the tests pass.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1626503002
Cr-Commit-Position: refs/heads/master@{#33474}
In case the receiver map has an enum cache, %ForInPrepare returns the
length of the actual enum cache, which might include properties that
are further down the transition tree tho.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1619353002
Cr-Commit-Position: refs/heads/master@{#33469}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33461}
Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!
Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1614313003
Cr-Commit-Position: refs/heads/master@{#33459}
Reason for revert:
the deopt issues have been taken care of by benedikt
Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1612413003
Cr-Commit-Position: refs/heads/master@{#33458}
The internal index used to implement for-in can never leave the
valid smi range, so there's no need to actually check for overflow
in Crankshaft. In fact the overflow only triggered a false alert
in the deopt fuzzer.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1621623002
Cr-Commit-Position: refs/heads/master@{#33456}
Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267
Review URL: https://codereview.chromium.org/1611313003
Cr-Commit-Position: refs/heads/master@{#33444}
Reason for revert:
tanks for-in significantly
Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n
Review URL: https://codereview.chromium.org/1619803003
Cr-Commit-Position: refs/heads/master@{#33443}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33438}
These features are not used by devtools and consequently not
exposed through the devtools protocol. They make the debugger
unnecessarily complex. If we decide that we need this, we should
implement this on a higher layer.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1607193003
Cr-Commit-Position: refs/heads/master@{#33436}
It was not properly rewriting three cases:
- [...[42]][0]
- [...[42]].length
- [...[42]] `foo` (which is a type error)
R=rossberg@chromium.org
BUG=v8:4696
LOG=N
Review URL: https://codereview.chromium.org/1617713002
Cr-Commit-Position: refs/heads/master@{#33433}
We divide character ranges into
- BMP, matched normally.
- non-BMP, matched as alternatives of surrogate pair ranges.
- lone surrogates, matched with lookaround assertion that its indeed lone.
R=erik.corry@gmail.com
BUG=v8:2952
LOG=N
Review URL: https://codereview.chromium.org/1578253005
Cr-Commit-Position: refs/heads/master@{#33432}
A break location is considered muted if it has break points, but their
conditions all evaluate to false. Aside from not triggering break
events, debugger statements and exceptions are also ignored.
R=verwaest@chromium.org
BUG=chromium:429167
LOG=Y
Review URL: https://codereview.chromium.org/1610073002
Cr-Commit-Position: refs/heads/master@{#33429}
This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.
R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1605633003
Cr-Commit-Position: refs/heads/master@{#33414}
This is to fix some of the failing test262 tests with ignition flag.
In few test262 tests, there is a throw from the script scope. Rewriter::Rewrite
pass converts expression statements into assignment statements in script scope.
This causes interpreter to fail because assignment expression expects a result
in accumulator but throw statement does not return a value. To fix this, we
now mark that accumulator contains a value when visiting throw statement.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1523423003
Cr-Commit-Position: refs/heads/master@{#33408}
Currently we fail to properly handle shadowed properties. If the
receiver defines a non-enumerable property that reappears on the
prototype as enumerable it incorrectly shows up in [[Enumerate]].
By extending the KeyAccumulator to track non-enumerable properties
we can now properly filter them out when seeing them further up in
the prototype-chain.
BUG=v8:705
LOG=y
Review URL: https://codereview.chromium.org/1608523002
Cr-Commit-Position: refs/heads/master@{#33405}
This patch implements one aspect of ES2015 RegExp subclassing:
String.prototype.replace is separated into two parts, a method on
RegExp.prototype in case the first argument is a RegExp, and the
String.prototype.replace method, which handles the string pattern
case. This separation is described in the ES2015 specification.
Most of the patch is simply moving code from string.js to regexp.js.
R=yangguo
LOG=Y
BUG=v8:4343
Review URL: https://codereview.chromium.org/1590673002
Cr-Commit-Position: refs/heads/master@{#33393}
Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.
BUG=v8:4280,v8:4676
LOG=N
Review URL: https://codereview.chromium.org/1595223004
Cr-Commit-Position: refs/heads/master@{#33384}
VisitObjectLiteral has two parts. First it creates a literal and then
sets properties or accessor properties. Setting properties requires a
runtime call and it expects the literal object which was created in the
first part is contiguous with other registers it allocates. Since these
are allocated in a different scope they are not always contiguous.
This causes problems with mjsunit/setter-on-constructor-prototype.js.
This cl fixes by allocating contiguous registers in the inner scope.
Literal value is copied into the newly allocated register so that all
the required registers are always contiguous.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1588903002
Cr-Commit-Position: refs/heads/master@{#33371}
This became temporarily a big issue, because spreads are desugared
into do-expressions. This patch fixes the problem with having
spreads as parameter initializers in arrow expressions, e.g., this
line would crash:
[], ((x = [...[42]]) => x)();
R=rossberg@chromium.org
BUG=chromium:578038
LOG=N
Review URL: https://codereview.chromium.org/1581403007
Cr-Commit-Position: refs/heads/master@{#33365}
