We should not skip holes for these 2 functions.
BUG=v8:3895
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1165003005
Cr-Commit-Position: refs/heads/master@{#28814}
We used to only store the uses_super_property in the preparse data
logger. Let the logger use NeedsHomeObject instead.
BUG=v8:3768
LOG=N
R=wingo, adamk
Review URL: https://codereview.chromium.org/1164073003
Cr-Commit-Position: refs/heads/master@{#28806}
This patch re-commits a previous commit after fixing a test to not
run into another known bug.
This reverts commit b104a67ef0.
This patch implements the last two methods on TypedArrays. These
were previously committed and led to a test failure.
BUG=v8:3578
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1159663004
Cr-Commit-Position: refs/heads/master@{#28803}
This fixes a corner-case where arrow functions that require a context
allocate none, because there are no additional slots allocated. Note
that this didn't happen with true function scopes because they always
had at least the receiver slot.
The outcome was a context chain that no longer was in sync with the
scope chain, hence context slot loads were bogus. This is observable
using the DYNAMIC_LOCAL optimization in all compilers.
R=rossberg@chromium.org,wingo@igalia.com
TEST=mjsunit/harmony/regress/regress-4160
BUG=v8:4160
LOG=N
Review URL: https://codereview.chromium.org/1146063006
Cr-Commit-Position: refs/heads/master@{#28788}
This patch implements the last two methods on TypedArrays. These
were previously committed and led to a test failure.
BUG=v8:3578
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1154423014
Cr-Commit-Position: refs/heads/master@{#28773}
This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.
This is a revert of the revert 88b1c9170a
BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org
Review URL: https://codereview.chromium.org/1168513004
Cr-Commit-Position: refs/heads/master@{#28769}
Implementations factored out from Array. Tests are derived from
normal array toString tests.
BUG=v8:3578
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1166623004
Cr-Commit-Position: refs/heads/master@{#28766}
This also fixes issues with
- kMaxUint32 being a valid length but not index cornercases
- exotic integer objects masking "exotic indexes" even though its in the prototype chain
- concating of holey sloppy arguments
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1159433003
Cr-Commit-Position: refs/heads/master@{#28754}
Stage 1 implementation:
- Parameters can't be referenced before initialized (from left-to-right)
- SingleNameBindings only, no support for BindingPatterns
Known issues:
- Incorrect scoping (parameter expressions may reference variables declared in function body)
- Function arity is untouched
- Hole-checking needs work
- Rest parameters are broken when mixed with optional arguments
BUG=v8:2160
LOG=N
R=arv@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1127063003
Cr-Commit-Position: refs/heads/master@{#28739}
This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.
BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org
Review URL: https://codereview.chromium.org/1146863007
Cr-Commit-Position: refs/heads/master@{#28731}
Implements the strong mode proposal's restrictions on the behaviour of the
delete operator for strong objects.
Setting the strong bit is still wip, so this change will only affect those
objects that have the bit correctly set. The tests reflect this, and will be
expanded as more objects can be marked as strong.
Attempt 2, last version did not work with API.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1156573002
Cr-Commit-Position: refs/heads/master@{#28724}
The point of this change is so that when emitting code for a call in
FullCodegen::VisitCall, the statement position is not associated to
any code that loads the function, but to the actual CallIC.
R=mvstanton@chromium.org
BUG=chromium:481896
LOG=N
Review URL: https://codereview.chromium.org/1157543004
Cr-Commit-Position: refs/heads/master@{#28701}
Implements the strong mode proposal's restrictions on changing a strong object's
writable, non-configurable property to non-writable.
Setting the strong bit is still wip, so this change will only affect those
objects that have the bit correctly set. The tests reflect this, and will be
expanded as more objects can be marked as strong.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1142393003
Cr-Commit-Position: refs/heads/master@{#28698}
Implements the strong mode proposal's restrictions on the ability of user code
to modify the prototype of strong objects.
Setting the strong bit is still wip, so this change will only affect those
objects that have the bit correctly set. The tests reflect this, and will be
expanded as more objects can be marked as strong.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1143623002
Cr-Commit-Position: refs/heads/master@{#28664}
Strong Object/Array literals are currently being created with incorrect
internal prototypes. This CL fixes this and extends the test suite to check.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1158933002
Cr-Commit-Position: refs/heads/master@{#28655}
When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:
method() {
var .home_object = %ThisFunction()[home_object_symbol];
...
}
BUG=v8:3867, v8:4031
LOG=N
Review URL: https://codereview.chromium.org/1135243004
Cr-Commit-Position: refs/heads/master@{#28644}
The April 14 2015 final draft of the ES6 specification states that the
`prototype` property of generator function instances should be writable.
BUG=v8:4140, v8:4140
LOG=N
R=arv@chromium.org
Review URL: https://codereview.chromium.org/1153633003
Cr-Commit-Position: refs/heads/master@{#28641}
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code. The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++. Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.
Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
In a similar vein we could give the magic zero hash code to the hash code
symbol. Then when we look up the hash code we would sometimes see the table
with all the hidden properties. This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS. I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.
R=adamk@chromium.org, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1149863005
Cr-Commit-Position: refs/heads/master@{#28622}
This fixes a corner-case where deoptimization while evaluating the
value to a __proto__ property after computed property names appeared
in an object literal, lead to environments not being in sync with
unoptimized code.
R=arv@chromium.org
TEST=mjsunit/harmony/computed-property-names-deopt
Review URL: https://codereview.chromium.org/1158443004
Cr-Commit-Position: refs/heads/master@{#28613}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28594}
Reason for revert:
breaks build
Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1149203003
Cr-Commit-Position: refs/heads/master@{#28589}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28588}
First steps only, the TurboFan compilation is still triggered from C++ land.
Includes some simplifications/cleanups, too.
Review URL: https://codereview.chromium.org/1150263002
Cr-Commit-Position: refs/heads/master@{#28581}
Also support patterns in ``for (var p in/of ...)``
This CL extends the rewriting we used to do for ``for (let p in/of...)`` to
``for (var p in/of ...)``. For all for..in/of loop declaring variable,
we rewrite
for (var/let/const pattern in/of e) b
into
for (x' in/of e) { var/let/const pattern = e; b }
This adds a small complication for debugger: for a statement
for (var v in/of e) ...
we used to have
var v;
for (v in/of e) ...
and there was a separate breakpoint on ``var v`` line.
This breakpoint is actually useless since it is immediately followed by
a breakpoint on evaluation of ``e``, so this CL removes that breakpoint
location.
Similiraly, for let, it used to be that
for (let v in/of e) ...
became
for (x' in/of e) { let v; v = x'; ... }
``let v``generetaed a useless breakpoint (with the location at the
loop's head. This CL removes that breakpoint as well.
R=arv@chromium.org,rossberg@chromium.org
BUG=v8:811
LOG=N
Review URL: https://codereview.chromium.org/1149043005
Cr-Commit-Position: refs/heads/master@{#28565}
This allows you to put iterables into your array literals
and the will get spread into the array.
let x = [0, ...range(1, 3)]; // [0, 1, 2]
This is done by treating the array literal up to the first
spread element as usual, including using a boiler plate
array, and then appending the remaining expressions and rest
expressions.
BUG=v8:3018
LOG=N
Review URL: https://codereview.chromium.org/1125183008
Cr-Commit-Position: refs/heads/master@{#28534}
Previously this patch was attempted with reduce and reduceRight included;
however, some of those tests crashed in the trybots. This version has
just map, fiter and some, together with their tests.
R=arv@chromium.org
BUG=v8:3578
LOG=Y
Review URL: https://codereview.chromium.org/1145013002
Cr-Commit-Position: refs/heads/master@{#28529}
This patch adds the two TypedArray methods indexOf and lastIndexOf,
which are similar to the methods on Arrays. Tests are ported from
arrays as well.
BUG=v8:3578
LOG=Y
R=arv@chromium.org
Review URL: https://codereview.chromium.org/1141763004
Patch from Daniel Ehrenberg <dehrenberg@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#28495}
The sort method of TypedArrays sorts in numerical order by default.
This patch implements sorting based on Arrays and adds a test.
The length of %TypedArray%.prototype.sort, like Array.prototype.sort,
seems to be unspecified in ES6, so this patch lets it have the value
1, to match our interpretation for Array.prototype.sort (though 0
would also be a sensible length).
R=arv@chromium.org
BUG=v8:3578
LOG=Y
Review URL: https://codereview.chromium.org/1148513002
Patch from Daniel Ehrenberg <dehrenberg@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#28494}
This patch adds the reverse method to TypedArrays, together with a
test. The test also runs for normal Arrays, since I didn't see a
test for reversing dense arrays.
BUG=v8:3578
LOG=Y
R=arv@chromium.org
Review URL: https://codereview.chromium.org/1132723008
Patch from Daniel Ehrenberg <dehrenberg@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#28493}
Also check whether the arguments count is smaller than the number of
required parameters which is the same as the SharedFunctionInfo length.
BUG=v8:4102
LOG=N
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1133933003
Cr-Commit-Position: refs/heads/master@{#28491}
This patch adds implementations for additional TypedArray methods
from the ES6 spec, together with tests adapted from array code.
R=arv@chromium.org
BUG=v8:3578
LOG=Y
Review URL: https://codereview.chromium.org/1139663005
Cr-Commit-Position: refs/heads/master@{#28488}
This function creates a new way to make TypedArrays based on existing
iterable or Array-like objects, analogous to Array.from. The patch
implements the function and adds tests.
R=arv@chromium.org
BUG=v8:3578
LOG=Y
Review URL: https://codereview.chromium.org/1132163011
Cr-Commit-Position: refs/heads/master@{#28456}
The functions of strong classes are born non extensible. But, when
the class is created we need to add an own private symbol representing
the [[HomeObject]] slot in the spec.
Like for the hidden_string property, we allow adding private own
symbols to non extensible objects.
BUG=v8:4077
LOG=N
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1138603003
Cr-Commit-Position: refs/heads/master@{#28447}
All the builtin iterators as well as the generator objects have an
object called %IteratorPrototype% in the spec between them and
%ObjectPrototype%.
BUG=v8:3568
LOG=N
Review URL: https://codereview.chromium.org/1128233008
Cr-Commit-Position: refs/heads/master@{#28426}
ES6 specifies that methods on TypedArrays reference an internal length
slot, rather than their length property. This patch tests that for the
TypedArray methods that exist currently.
R=arv@chromium.org
BUG=v8:3578
LOG=Y
Review URL: https://codereview.chromium.org/1130413010
Cr-Commit-Position: refs/heads/master@{#28409}
... and the following two
"PPC: Resolve references to "this" the same way as normal variables"
"Remove Scope::scope_uses_this_ flag"
R=hablich@chromium.org
BUG=chromium:487289
LOG=N
Review URL: https://codereview.chromium.org/1134003003
Cr-Commit-Position: refs/heads/master@{#28395}
This was already done for other binary operations, so it's basically
copying the existing functionality to shift left and shift right
logical/arithmetic.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1140883003
Cr-Commit-Position: refs/heads/master@{#28389}
Use these check points to optimize comparisons where we already know
that one side cannot be a String (or turn into a string via
ToPrimitive).
Also remove bunch of useless DoNotCrash tests for the scheduler that are
painful to maintain and add almost no value.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1140583004
Cr-Commit-Position: refs/heads/master@{#28383}
This patch adds three methods to TypedArrays which are already
implemented for arrays. The implementations are made by calling
out to the underlying code used by Arrays.
R=adamk@chromium.org
BUG=v8:3578
LOG=Y
Review URL: https://codereview.chromium.org/1136663005
Cr-Commit-Position: refs/heads/master@{#28382}
Implements the strong mode proposal's restrictions on implicit conversions
for the binary >, >=, <, and <= operators.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1130283002
Cr-Commit-Position: refs/heads/master@{#28370}
If there had been no debug listener v8::Debug::GetDebugContext would have created new context and wouln't have kept reference to it. This way we may well end up with several debug contexts and disabled debugger.
As a side effect this change allows to efficiently distinguish debug context from blink contexts by simply comparing handles.
BUG=chromium:482290
LOG=Y
Review URL: https://codereview.chromium.org/1136733002
Cr-Commit-Position: refs/heads/master@{#28356}
The idea is to make this the model for future TypedArray methods.
A possible downside could be lower array method performance
if everything gets polymorhpic (but if enough inlining happens, it
should still be fast), but on the upside, this change means that
the TypedArray methods won't create as much code size bloat.
BUG=v8:3578
LOG=Y
R=adamk@chromium.orgCC=arv@chromium.org, caitpotter88@gmail.com
Review URL: https://codereview.chromium.org/1133503003
Cr-Commit-Position: refs/heads/master@{#28351}
This patch:
- Refactors Parser::ParseVariableDeclarations
- Introduces Parser::PatternMatcher class
- Implements matching a single variable pattern
- Implements rudimentary matching against object literal pattern
as a proof of concept
R=arv@chromium.org,rossberg@chromium.org
BUG=v8:811
LOG=N
Review URL: https://codereview.chromium.org/1130623004
Cr-Commit-Position: refs/heads/master@{#28345}
Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.
Based on work by Adrian Perez de Castro <aperez@igalia.com>.
This is a reapplication of https://codereview.chromium.org/1130733003.
R=rossberg@chromium.org
BUG=v8:2700
LOG=N
Review URL: https://codereview.chromium.org/1136073002
Cr-Commit-Position: refs/heads/master@{#28340}
This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.
Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.
Review URL: https://codereview.chromium.org/1137703002
Cr-Commit-Position: refs/heads/master@{#28339}
Exposed to the extras as extrasExports (on the builtins object), on
which they can put things that should be accessible from C++. Exposed
to C++ through the V8 API as v8::Context::GetExtrasExportsObject().
Adding a test (in test-api.cc) required adding a simple extra,
test-extra.js, which we build into the standalone builds.
R=yangguo@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1128113006
Cr-Commit-Position: refs/heads/master@{#28317}
Reason for revert:
[Sheriff] Breaks jetstream benchmark with errors like this:
>>> Running suite: JetStream/bigfib.cpp
>>> Stdout (#1):
undefined:93: ReferenceError: this is not defined
this['Module'] = Module;
^
ReferenceError: this is not defined
at eval (eval at __run (runner.js:13:3), <anonymous>:93:3)
at eval (native)
at __run (runner.js:13:3)
at Object.runSimpleBenchmark (runner.js:44:31)
at runner.js:97:13
Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=v8:2700
> LOG=N
>
> Committed: https://crrev.com/06a792b7cc2db33ffce7244c044a9c05afbb6116
> Cr-Commit-Position: refs/heads/master@{#28263}
TBR=rossberg@chromium.org,arv@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2700
Review URL: https://codereview.chromium.org/1129723003
Cr-Commit-Position: refs/heads/master@{#28283}
Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.
Based on work by Adrian Perez de Castro <aperez@igalia.com>.
BUG=v8:2700
LOG=N
Review URL: https://codereview.chromium.org/1130733003
Cr-Commit-Position: refs/heads/master@{#28263}
The Hydrogen representation for binops was never changed to care about the
language mode. We thought this was ok, but it turns out we need to keep track
of it to make sure inlining doesn't mess with the "strongness" of binops.
Also added more rigorous inlining testing.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1123043002
Cr-Commit-Position: refs/heads/master@{#28253}
ArgumentsAdaptorStub for derived constructor (the one that needs
new.target) works in this way:
- If the constructor is invoked via the Construct stub, we know that
actual arguments always include new.target. ``arguments`` object
however should not include a new.target, therefore we remove it.
We achieve this by decrementing the argument count.
- If the constructor is invoked as a call, we do not care for a correct
``arguments`` array since the constructor will immediately throw on
entrance.
The bug is that the call could actually pass 0 actual arguments, but I
decrement unconditionally :(. The fix is to detect this case and avoid
decrementing. ``arguments`` is bogus, but it is ok as constructor
throws.
Long-term we should just remove mucking about with arguments for
new.target and just get it from the stack.
R=arv@chromium.org,rossberg@chromium.org
BUG=chromium:474783
LOG=Y
Review URL: https://codereview.chromium.org/1126783003
Cr-Commit-Position: refs/heads/master@{#28242}
Reason for revert:
nosnap failures
Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=
> LOG=N
>
> Committed: https://crrev.com/18619d355192e2699203d12d9ebb9caea107b693
> Cr-Commit-Position: refs/heads/master@{#28236}
TBR=rossberg@chromium.org,mstarzinger@chromium.org,dslomov@chromium.org,adamk@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1113133006
Cr-Commit-Position: refs/heads/master@{#28238}
Reason for revert:
All sorts of performance regressions
Original issue's description:
> Collect type feedback on result of Math.[round|ceil|floor]
>
> By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.
>
> Committed: https://crrev.com/f36ecaf3a4d61568ca50a20718acce7dd5da9a5f
> Cr-Commit-Position: refs/heads/master@{#28215}
TBR=mvstanton@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1115973005
Cr-Commit-Position: refs/heads/master@{#28237}
Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.
Based on work by Adrian Perez de Castro <aperez@igalia.com>.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1097283003
Cr-Commit-Position: refs/heads/master@{#28236}
When comparing a symbol to istself using <, <=, > or >= we need to
throw a TypeError. This is correctly handled in the runtime function
so if we are comparing a symbol fall back to use the runtime.
BUG=v8:4073
LOG=Y
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1125783002
Cr-Commit-Position: refs/heads/master@{#28226}
By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.
Review URL: https://codereview.chromium.org/1053143005
Cr-Commit-Position: refs/heads/master@{#28215}
Implements the strong mode proposal's restrictions on implicit conversions
for the binary + operator. Test suite is also cleaned up/refactored to allow
easier testing of the comparison operators in the future.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1109223004
Cr-Commit-Position: refs/heads/master@{#28159}
The goal is to port all of error stack trace formatting to C++.
We will do this bottom up, by first porting helper functions.
Eventually, CallSite methods will only be used when a custom
error stack trace formatter is defined via Error.prepareStackTrace.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1060583008
Cr-Commit-Position: refs/heads/master@{#28095}
...when handing out validity cells to handlers; because invalidating said cells is
the only time we'll need the user registrations.
Along the way, fix a corner case in WeakFixedArray, which can now be empty after
the recently introduced compaction support.
This reverts commit 968715c653.
Original review: https://codereview.chromium.org/1104813004/
Review URL: https://codereview.chromium.org/1110513002
Cr-Commit-Position: refs/heads/master@{#28076}
If the array's map is the initial FastHoley array map, and the array prototype
chain is undisturbed and empty of elements, then keyed loads can convert the
load of a hole to undefined.
BUG=
Review URL: https://codereview.chromium.org/1100083002
Cr-Commit-Position: refs/heads/master@{#28056}
This reverts commit d5565c1f68.
Getter and setter function names in ES6 are defined as "get foo" and
"set foo".
This also moves the logic for handling symbols from runtime-function.cc
to v8natives.js.
BUG=None
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1093183006
Cr-Commit-Position: refs/heads/master@{#28050}
Reason for revert:
Suspected of causing GC stress failures.
Original issue's description:
> Lazily register prototype users
>
> when handing out validity cells to handles; because invalidating said cells is the only time we'll need the user registrations.
> Along the way, fix a corner case in WeakFixedArray, which can now be empty after the recently introduced compaction support.
>
> Committed: https://crrev.com/a4bb7643c076b014816431a9b85af3e2edf828e7
> Cr-Commit-Position: refs/heads/master@{#28047}
TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1108583002
Cr-Commit-Position: refs/heads/master@{#28049}
when handing out validity cells to handles; because invalidating said cells is the only time we'll need the user registrations.
Along the way, fix a corner case in WeakFixedArray, which can now be empty after the recently introduced compaction support.
Review URL: https://codereview.chromium.org/1104813004
Cr-Commit-Position: refs/heads/master@{#28047}
Implements the strong mode proposal's restrictions on
implicit conversions for binary arithmetic operations, not
including the + special case. Adds some infrastructure
for future implementation of the restrictions for other
operators.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1092353002
Cr-Commit-Position: refs/heads/master@{#28045}
This introduces a bailout point for class literals right after the
%DefineClass function has been called. Otherwise the FrameState after
class literal evaluation might contain the literal itself.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-480819
BUG=chromium:480819
LOG=N
Review URL: https://codereview.chromium.org/1104673004
Cr-Commit-Position: refs/heads/master@{#28043}
Add the restriction that both classes must be declared inside the same
consectutive class declaration batch.
Dependency analysis not implemented yet.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1060913005
Cr-Commit-Position: refs/heads/master@{#28032}
A strict arrow function with no parameters and no variable bindings
won't need a context object because it will never have any
locals. (This is unlike strict normal functions, which do have
"arguments" and "this" locals.)
R=rossberg@chromium.org
BUG=v8:4056
LOG=N
Review URL: https://codereview.chromium.org/1093183003
Cr-Commit-Position: refs/heads/master@{#28031}
ES6 specifies the function name property (it was not part of ES5) and
it specifies the name of Function.prototype to the empty string ("" and
not "Empty"). This makes us match Firefox, Safari and IE developer
preview.
BUG=v8:4033
LOG=N
R=adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1080393004
Cr-Commit-Position: refs/heads/master@{#28021}
Reason for revert:
Was an infrastructure problem.
Original issue's description:
> Revert of [strong] checking of this & super in constructors (patchset #7 id:110001 of https://codereview.chromium.org/1024063002/)
>
> Reason for revert:
> [Sheriff] Breaks mac gc stress:
> http://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/1024
>
> Original issue's description:
> > [strong] checking of this & super in constructors
> >
> > R=dslomov@chromium.org, marja@chromium.org
> > BUG=v8:3956
> > LOG=N
> >
> > Enforces for constructors that
> > - the only use of 'super' is the super constructor call
> > - the only use of 'this' is a property assignment
> > - both of these must happen at the top-level of the body
> > - 'this' may only be assigned after the 'super' call
> > - 'return' may only be used after the last assignment to 'this'
> >
> > Not yet working for arrow functions (there might be deeper bugs with those).
> >
> > Committed: https://crrev.com/580d66bcda66220d2f3062ac58daf925436df74c
> > Cr-Commit-Position: refs/heads/master@{#27977}
>
> TBR=dslomov@chromium.org,marja@chromium.org,conradw@chromium.org,rossberg@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:3956
TBR=dslomov@chromium.org,marja@chromium.org,conradw@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3956
Review URL: https://codereview.chromium.org/1073103004
Cr-Commit-Position: refs/heads/master@{#28001}
Reason for revert:
This was probably an infrastructure problem caused by the mac ninja/goma switch.
Original issue's description:
> Revert of Protect the emptiness of Array prototype elements with a PropertyCell. (patchset #7 id:120001 of https://codereview.chromium.org/1092043002/)
>
> Reason for revert:
> MAC GCSTRESS failure on new test.
>
> Original issue's description:
> > Protect the emptiness of Array prototype elements with a PropertyCell.
> >
> > Not just emptiness, but also a particular structure.
> >
> > BUG=v8:4044
> > LOG=N
>
> TBR=jkummerow@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4044
TBR=jkummerow@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4044
Review URL: https://codereview.chromium.org/1052253003
Cr-Commit-Position: refs/heads/master@{#28000}
Reason for revert:
MAC GCSTRESS failure on new test.
Original issue's description:
> Protect the emptiness of Array prototype elements with a PropertyCell.
>
> Not just emptiness, but also a particular structure.
>
> BUG=v8:4044
> LOG=N
TBR=jkummerow@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4044
Review URL: https://codereview.chromium.org/1099203004
Cr-Commit-Position: refs/heads/master@{#27998}
Not just emptiness, but also a particular structure.
BUG=v8:4044
LOG=N
Review URL: https://codereview.chromium.org/1092043002
Cr-Commit-Position: refs/heads/master@{#27993}
Reason for revert:
[Sheriff] Breaks mac gc stress:
http://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/1024
Original issue's description:
> [strong] checking of this & super in constructors
>
> R=dslomov@chromium.org, marja@chromium.org
> BUG=v8:3956
> LOG=N
>
> Enforces for constructors that
> - the only use of 'super' is the super constructor call
> - the only use of 'this' is a property assignment
> - both of these must happen at the top-level of the body
> - 'this' may only be assigned after the 'super' call
> - 'return' may only be used after the last assignment to 'this'
>
> Not yet working for arrow functions (there might be deeper bugs with those).
>
> Committed: https://crrev.com/580d66bcda66220d2f3062ac58daf925436df74c
> Cr-Commit-Position: refs/heads/master@{#27977}
TBR=dslomov@chromium.org,marja@chromium.org,conradw@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3956
Review URL: https://codereview.chromium.org/1105453002
Cr-Commit-Position: refs/heads/master@{#27991}
R=dslomov@chromium.org, marja@chromium.org
BUG=v8:3956
LOG=N
Enforces for constructors that
- the only use of 'super' is the super constructor call
- the only use of 'this' is a property assignment
- both of these must happen at the top-level of the body
- 'this' may only be assigned after the 'super' call
- 'return' may only be used after the last assignment to 'this'
Not yet working for arrow functions (there might be deeper bugs with those).
Review URL: https://codereview.chromium.org/1024063002
Cr-Commit-Position: refs/heads/master@{#27977}
We have a bottleneck around storing elements in the array and object prototypes,
but the Push() and Unshift() builtins don't respect them.
Fix this exactly to the level of existing support for stores.
BUG=v8:4043
LOG=N
NOTRY=true
Review URL: https://codereview.chromium.org/1066003003
Cr-Commit-Position: refs/heads/master@{#27943}
This adds a stripped down version of the SQLite benchmark (running with
--size 1) to the mjsunit suite. We might want to move that to a
dedicated slow/stress/whatever test suite once an appropriate decision
is made.
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/1094043002
Cr-Commit-Position: refs/heads/master@{#27930}
The previous restrictions were overshooting (didn't allow a class to refer to a
later class under any circumstances); after this CL we're undershooting (allow
referring to any class from inside a method).
Implementing the correct checks (allow referring only if the class declarations
are in a consecutive block and if there's no dependency cycle) will be
implemented as a follow up.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1087543004
Cr-Commit-Position: refs/heads/master@{#27888}
Implements the strong mode proposal's restrictions on the syntax of the
switch statement. Also fixes a minor bug with empty statements in strong
mode and improves StrongUndefinedArrow parser synch tests.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1084983002
Cr-Commit-Position: refs/heads/master@{#27885}
This reverts commit 8c98cc074e
because it causes flaky failures in the dromaeo.jslibeventprototype
benchmark on Linux/Windows and consistent failures on Android.
Also reverts the followup "Remove kForInStatementIsNotFastCase bailout reason"
(commit ba24e67696) to avoid breaking the build.
BUG=chromium:476592
TBR=verwaest@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1066663005
Cr-Commit-Position: refs/heads/master@{#27859}
Calling new Array(JSObject::kInitialMaxFastElementArray) in optimized code
makes a stub call that bails out due to the length. Currently, the bailout
code a) doesn't have the allocation site, and b) wouldn't use it if it did
because the length is perceived to be too high.
This CL passes the allocation site to the stub call (rather than undefined),
and alters the bailout code to utilize the feedback.
BUG=
Review URL: https://codereview.chromium.org/1086873003
Cr-Commit-Position: refs/heads/master@{#27857}
In ES6 function name and length are configurable. However, the length
and name properties of the poison pill function must not be
configurable.
BUG=v8:4011
LOG=N
R=adamk@chromium.org, rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1061393002
Cr-Commit-Position: refs/heads/master@{#27855}
This adds a missing bailout id to a ForInStatement for when retrieving
and filtering a property name deoptimizes. This can happen with proxies
that have a getPropertyDescriptor trap.
R=jarin@chromium.org
TEST=mjsunit/for-in-opt
Review URL: https://codereview.chromium.org/1086083002
Cr-Commit-Position: refs/heads/master@{#27846}
Instead of modifying a context chain and then modifying it back, causing
potential mismatches, we clone the inner context chain and evaluate
the expression in this cloned context. We then copy all local variable
values back if needed.
R=yangguo@chromium.org,yurys@chromium.org
Review URL: https://codereview.chromium.org/1088503003
Cr-Commit-Position: refs/heads/master@{#27809}
Does not entirely disallow the use of 'eval' as an identifier in strong mode,
as originally proposed.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1059273004
Cr-Commit-Position: refs/heads/master@{#27796}
Deoptimization infrastructure already handles it correctly.
This change fixes repetitive deoptimizations in the code like this:
var u32 = new Uint32Array(1);
u32[0] = -1;
function tr(x) { return x|0; }
function ld() { return tr(u32[0]); }
while (true) ld();
Currently inlined tr will contain HArgumentsObject that is considered uint32-unsafe use and prevents u32[0] from becoming uint32 load - instead a speculative int32 load is generated which just deopts.
BUG=
Review URL: https://codereview.chromium.org/1077113002
Cr-Commit-Position: refs/heads/master@{#27781}
This makes the compilers agree on the source position of a message
generated by "throw new Error()", it points to the beginning of the
throw directive.
R=titzer@chromium.org
TEST=message/regress/regress-3995
BUG=v8:3995
LOG=N
Review URL: https://codereview.chromium.org/1049703002
Cr-Commit-Position: refs/heads/master@{#27775}
The ES6 specification does not explicitly state the attributes for the
'next' and 'throw' property descriptors, so their values are defined by
Section 17 [1]:
> Every other data property described in clauses 18 through 26 and in
> Annex B.2 has the attributes
> { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }
> unless otherwise specified.
[1]
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-standard-built-in-objects
BUG=v8:3986
LOG=N
R=wingo,arv
Review URL: https://codereview.chromium.org/1051363003
Cr-Commit-Position: refs/heads/master@{#27770}
Implements the strong mode proposal's static restrictions on the use of the
identifier 'undefined', for arrow functions. Assumes these restrictions are
intended to be identical to the restrictions on the use of 'eval and 'arguments'
in strict mode. In addition, Location variables inconsistantly named (e.g.
dupe_error_loc vs dupe_loc) are now consistently named the shorter way.
Baseline: https://codereview.chromium.org/1070633002
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1060883004
Cr-Commit-Position: refs/heads/master@{#27756}
identifier. Delete unused (and now incorrect) function IsValidStrictVariable.
Implements the strong mode proposal's static restrictions on the use of the
identifier 'undefined'. Assumes these restrictions are intended to be identical
to the restrictions on the use of 'eval' and 'arguments' in strict mode. The
AllowEvalOrArgumentsAsIdentifier enum has been renamed to
AllowRestrictedIdentifiers as logic involving it is now also used for this case.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1070633002
Cr-Commit-Position: refs/heads/master@{#27744}
Currently we always generate a diamond in the graph builder for every
legacy const context slot, which we cannot get rid of until late control
reduction, even if we know after context specialization that the slot is
already initialized.
Now we generate a select instead, which the CommonOperatorReducer
happily removes during typed lowering. This greatly speeds up asm.js
code generated by Emscripten with the new POINTER_MASKING mode.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1072353002
Cr-Commit-Position: refs/heads/master@{#27739}
When ObjectToString is installed on Object.prototype twice (once in v8natives.js, and once in harmony-tostring.js), this pollutes old code spaces on some devices. To prevent this, the function is only installed once, preventing test failures when the --harmony-tostring flag is flipped on by default.
BUG=v8:3502
LOG=N
R=arv@chromium.org
Review URL: https://codereview.chromium.org/1072083002
Cr-Commit-Position: refs/heads/master@{#27720}
This is a workaround to make the debugger happy about TurboFan frames
when the debugger causes frame inspection. Note that this can happen
because the debugger can be activated while there still are optimized
TurboFan activations on the stack.
R=ishell@chromium.org
BUG=chromium:465298
TEST=mjsunit/regress/regress-crbug-465298
LOG=N
Review URL: https://codereview.chromium.org/1074793003
Cr-Commit-Position: refs/heads/master@{#27717}
Those two tests fail in gc-stress and custom snapshot (embedding mjsunit.js).
This is likely due to different GC timing with the custom snapshot.
R=mstarzinger@chromium.org
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1078653002
Cr-Commit-Position: refs/heads/master@{#27688}
If we optimize a function before gathering feedback it may be
peppered with soft deoptimizations. So it can't help but deoptimize.
A judicious reading of the code isn't enough to determine what the
optimization state should be in the face of such chaotic gyrations.
BUG=
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1069363003
Cr-Commit-Position: refs/heads/master@{#27671}
This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1053063003
Cr-Commit-Position: refs/heads/master@{#27633}
The motivation is that we prefer to avoid creating internal properties, and we have a usable field on maps ("transitions", which is not used for prototype maps).
This CL also ensures the invariant that prototype maps are never shared, even if they are in dictionary mode.
Review URL: https://codereview.chromium.org/1033653002
Cr-Commit-Position: refs/heads/master@{#27617}
Optimistically pushing a lot of arguments can run into the stack limit of the process, at least on operating systems where this limit is close to the limit that V8 sets for itself.
BUG=chromium:469768
LOG=y
Review URL: https://codereview.chromium.org/1056913003
Cr-Commit-Position: refs/heads/master@{#27614}
From ES6 25.2.3 ("Properties of the GeneratorFunction Prototype
Object"):
> The GeneratorFunction prototype object is an ordinary object. It is
> not a function object and does not have an [[ECMAScriptCode]] internal
> slot or any other of the internal slots listed in Table 27 or Table
> 56.
Introduce one assertion for the value's type and additional tests for its
properties. Remove an invalid assertion that fails as a result of this
fix.
BUG=v8:3991
LOG=N
Review URL: https://codereview.chromium.org/1062633002
Cr-Commit-Position: refs/heads/master@{#27603}
In ES6 Object.getOwnPropertyDescriptor should call ToObject, which
means that primitive values will return descriptors from the wrapper.
BUG=v8:3964
LOG=N
R=adamk, rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/998163004
Cr-Commit-Position: refs/heads/master@{#27569}
The removed assertion consistently passes not because the invoked
`close` method internally throws a `TypeError` but because the `close`
method does not exist. The ES6 specification does not define a `close`
method on the GeneratorPrototype, so this test is a tautology.
BUG=None
LOG=N
R=arv
Review URL: https://codereview.chromium.org/1046963002
Cr-Commit-Position: refs/heads/master@{#27567}
The modified assertions targeted the property descriptor for the
template object's first "cooked" value. The code immediately preceeding
these statements asserts these values.
Update the assertions to instead target the property descriptor for the
template object's first "raw" value (which are otherwise untested).
BUG=
Review URL: https://codereview.chromium.org/1049523003
Cr-Commit-Position: refs/heads/master@{#27566}
This reverts commit 992751d0dc.
The final spec for Object.getPrototypeOf calls ToObject on the
parameter, which means that it should only throw for null and
undefined. For other non object values the prototype of the wrapper
should be used.
Difference from last time: Updated .status and will disable Blink
side tests as needed.
BUG=v8:3964
LOG=N
R=adamk, rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1051523003
Cr-Commit-Position: refs/heads/master@{#27558}
The spec settled on ToBoolean instead of only using not undefined.
BUG=v8:3827
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1045113002
Cr-Commit-Position: refs/heads/master@{#27548}
This test will fail once we optimize top-level code, because the
aforementioned intrinsic doesn't perform a NumberToUint32 conversion.
R=titzer@chromium.org
TEST=mjsunit/asm/math-clz32
Review URL: https://codereview.chromium.org/1041173002
Cr-Commit-Position: refs/heads/master@{#27524}
A bug allows JSObject literals with elements to have the elements in the
boilerplate modified.
BUG=466993
LOG=N
Review URL: https://codereview.chromium.org/1037273002
Cr-Commit-Position: refs/heads/master@{#27511}
On 'debugger' statement, if anything in debugger calls 'EnsureDebugInfo'
on a function, EnsureDebugInfo would compile and substitute code without
debug break slots. This causes weird behavior later when stepping fails
to work (see added test as an example).
This fix is to make sure the debugger is prepared for breakpoints in
that case as well.
Also adds extra testing for bug 468661.
R=yangguo@chromium.org,yurys@chromium.orh
BUG=v8:3990,chromium:468661
LOG=N
Review URL: https://codereview.chromium.org/1032353002
Cr-Commit-Position: refs/heads/master@{#27502}
Only one FrameInspector can be active at a time on any given stack,
this ensures that it's lifetime is sufficiently scoped.
R=yangguo@chromium.org
TEST=mjsunit/regress/regress-crbug-259300
Review URL: https://codereview.chromium.org/1034743002
Cr-Commit-Position: refs/heads/master@{#27477}
Instead of CanRetainOtherContext, we now manually blacklist all access-checked objects.
BUG=
Review URL: https://codereview.chromium.org/1020803004
Cr-Commit-Position: refs/heads/master@{#27473}
This method uses in messages.js in GetSourceLine and GetPositionInLine. This methods uses in v8::Message API methods and there is no documentation about it.
Method looks obsolete.
One of the strange side effect is shown by attached issue.
BUG=chromium:468781
TBR=yangguo@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1033973002
Cr-Commit-Position: refs/heads/master@{#27458}
This adapts the debugger so that the first break event starting the
stepping process can come from optimized code. TurboFan supports a
debugger statement and hence can be the top-most frame whenever the
Debug::HandleDebugBreak handler is triggered.
R=yangguo@chromium.org
TEST=mjsunit/debug,cctest/test-debug
Review URL: https://codereview.chromium.org/1038613002
Cr-Commit-Position: refs/heads/master@{#27447}
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 root cause for the bug is that the positions assigned to desugared
code was inconsistent with the source ranges of block scopes.
Since the fact that the position is assigned causes the debugger to
break at the parser-generated statement, the fix is to remove positions
from those nodes that we do not want to break on.
The CL also teaches Hydrogen to tolerate these cases.
R=adamk@chromium.org,rossberg@chromium.org
BUG=chromium:468661
LOG=Y
Review URL: https://codereview.chromium.org/1032653002
Cr-Commit-Position: refs/heads/master@{#27424}
Gather references to unbound variables where the reference (VariableProxy) is
inside strong mode. Check them against the global object when a script is bound
to a context (during compilation).
This CL only checks unbound variables which are not inside lazy functions - TBD
how do we solve that; alternatives: add developer mode which disables laziness /
do the check whenever lazy functions are really compiled.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1005063002
Cr-Commit-Position: refs/heads/master@{#27422}
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}
Reason for revert:
Layout test failures. Please update layout test expectations before landing this, in order to not block the roll.
Original issue's description:
> [es6] Object.getPrototypeOf should work with values
>
> The final spec for Object.getPrototypeOf calls ToObject on the
> parameter, which means that it should only throw for null and
> undefined. For other non object values the prototype of the wrapper
> should be used.
>
> BUG=v8:3964
> LOG=N
> R=adamk, rossberg@chromium.org
>
> Committed: https://crrev.com/ea463a916bbe5994b0d2d04e8075058b373b2e2c
> Cr-Commit-Position: refs/heads/master@{#27354}
TBR=adamk@chromium.org,rossberg@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3964
Review URL: https://codereview.chromium.org/1033623002
Cr-Commit-Position: refs/heads/master@{#27389}
Handlers should be in charge of this work. The change uncovered a bug in
vector-ics related to keyed loads into strings. It's important for
StringCharCodeAtGenerator, a helper used in full code and in
LoadIndexedStringStub (a handler) to protect the vector and slot registers
when it makes a runtime call to convert a HeapNumber to a Smi.
It's still possible for the handler to MISS after this call, perhaps due
to out of bounds access. In that case, the vector and slot registers need
to be delivered safely to the MISS handler.
BUG=
Review URL: https://codereview.chromium.org/1028093002
Cr-Commit-Position: refs/heads/master@{#27377}
This method uses in messages.js in GetSourceLine and GetPositionInLine. This methods uses in v8::Message API methods and there is no documentation about it.
Method looks obsolete.
One of the strange side effect is shown by attached issue.
BUG=chromium:468781
R=yangguo@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1022333004
Cr-Commit-Position: refs/heads/master@{#27374}
15.5.4.6 5.b requires each part to be converted using ToString(). This also needs to occur in the single argument fast-case.
BUG=v8:3981
R=arv@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1029103002
Cr-Commit-Position: refs/heads/master@{#27372}
The final spec for Object.getPrototypeOf calls ToObject on the
parameter, which means that it should only throw for null and
undefined. For other non object values the prototype of the wrapper
should be used.
BUG=v8:3964
LOG=N
R=adamk, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1014813003
Cr-Commit-Position: refs/heads/master@{#27354}
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}
With this change, we remember the types of frame state inputs (in a new
operator, called TypedStateValues). Instead of inferring the value types
when building translations, we used the recorded types.
The original approach was not reliable because the passes after
simplified lowering can change node types, and this in turn confuses
the translation builder.
BUG=chromium:468727
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1015423002
Cr-Commit-Position: refs/heads/master@{#27310}
When the debugger is active, a host of connected functions get an associated
DebugInfo structure, and their code is copied. The debugger uses the original
code to occasionally patch ICs with their initial value. Although IC learning
can occur, it's thrown away often, depending on the constellation of
breakpoints active or deactivating. Finally, feedback is discarded when the
debugger is turned off.
The type feedback vector needs to be brought into line with this behavior, so
now the debugger clears it's IC slots at appropriate bottlenecks in debug.cc.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1014373002
Cr-Commit-Position: refs/heads/master@{#27289}
Updated excludes to remove SKIPs where possible. Either
removing if no longer needed or replacing with SLOW where
tests just need more time to run
modified: test/cctest/cctest.status
modified: test/mjsunit/mjsunit.status
R=danno@chromium.org, svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1017073003
Cr-Commit-Position: refs/heads/master@{#27287}
The change introduces a second frame state (for the state before
the operation) for the StoreProperty nodes. If the store writes
into a typed array, the frame state is used for lazy deopt from
the to-number conversion that is performed by the store.
BUG=v8:3963
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/997983004
Cr-Commit-Position: refs/heads/master@{#27285}
