Currently, the desugaring of for loops of the form for
(let/const ...; bla; bla) causes them to always have a
completion value of 1, regardless of whether the loop body
is executed or not. This CL fixes this, realigning
initializer blocks as a more general purpose way to avoid
the completion value rewriter (since that's all they really
do anyway).
BUG=
Review URL: https://codereview.chromium.org/1177053006
Cr-Commit-Position: refs/heads/master@{#29108}
This fixes a bug where new-space GC could be triggered by non-folded allocations for some of the in-object properties, while the object was only partially initialized.
BUG=chromium:500497
LOG=y
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/1182113007
Cr-Commit-Position: refs/heads/master@{#29079}
According to the ES6 spec, the main methods and getters shouldn't
be properties of the individual TypedArray objects and prototypes
but instead on %TypedArray% and %TypedArray%.prototype. This
difference is observable through introspection. This patch moves
some methods and getters to the proper place, with the exception
of %TypedArray%.prototype.subarray and harmony methods. These will
be moved in follow-on patches.
BUG=v8:4085
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1186733002
Cr-Commit-Position: refs/heads/master@{#29057}
This patch includes the following changes.
1, Enable the turbofan backend support for X87 platform. It depends on previous CL: 3fdfebd26.
2, Enable the test cases which are disabled because turbofan for X87 was not enabled.
BUG=v8:4135
LOG=N
Review URL: https://codereview.chromium.org/1179763004
Cr-Commit-Position: refs/heads/master@{#29049}
This invariant will save us some head ache.
The changes to test-debug/DebugStub is due to the fact that it abuses
the ability to set break points in code that has no debug break slots.
This is now no longer possible.
R=ulan@chromium.org
BUG=v8:4132
LOG=N
Review URL: https://codereview.chromium.org/1181013007
Cr-Commit-Position: refs/heads/master@{#29038}
In ES6, the TypedArray constructor can be called either with an
array-like object or an iterable. The code previously handled
only array-like objects. This patch switches to supporting
iterables while throwing in an optimization to make Arrays
get allocated the old way, without an extra copy.
BUG=v8:4090
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1181903003
Cr-Commit-Position: refs/heads/master@{#29031}
This fixes the graph wiring of implicit JSToNumber nodes inserted by
JSTypedLowering, to be correctly hooked into a surrounding exceptional
continuation.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/try-binop,test262
Review URL: https://codereview.chromium.org/1178153004
Cr-Commit-Position: refs/heads/master@{#28975}
The spec says ToObject is called on the receiver, and this is
observable if you call sort on a primitive. This patch trivially
adds the call and a test.
BUG=v8:4125
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1178193004
Cr-Commit-Position: refs/heads/master@{#28972}
%AddElement is not intended for objects which are not arrays, and
its behavior may go away with future refactorings. This patch gets
rid of it if the receiver of from or of is not the intrinsic Array
object.
Array.of and Array.from previously papered over failures in calling
[[DefineOwnProperty]] when setting array elements. This patch
makes them lead to exceptions, and adds tests to assert that
the appropriate exceptions are thrown.
BUG=v8:4168
R=adamk
CC=rossberg,verwaest
LOG=Y
Review URL: https://codereview.chromium.org/1181623003
Cr-Commit-Position: refs/heads/master@{#28969}
Reason for revert:
Test failures are bogus. Snapshot blob and natives blob are out of sync due to build being weird.
Original issue's description:
> Revert of Promise assimilation fix. (patchset #8 id:160001 of https://codereview.chromium.org/1098663002/)
>
> Reason for revert:
> Test failures: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux64/builds/3829
>
> Original issue's description:
> > Promise assimilation fix.
> >
> > Let x be a fulfilled promise and y be another promise. |x.then(() => y)|
> > should call |y.then|, but the current implementation calls PromiseChain.
> > We can see the difference when we set a custom function to |y.then|.
> >
> > This CL fixes the spec violation, but as a result |then| is no longer
> > a wrapper of |chain| and in some cases it does not work well with
> > |accept| or |chain|. That is not a problem for ES6 promise users because
> > ES6 promise doesn't have them.
> >
> > LOG=N
> > BUG=477921
> >
> > Committed: https://crrev.com/2f57dff3ea0c45e1a61b334fda962460f89d71bc
> > Cr-Commit-Position: refs/heads/master@{#28926}
>
> TBR=arv@chromium.org,caitpotter88@gmail.com,rossberg@chromium.org,yhirano@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=477921
>
> Committed: https://crrev.com/5bb75f514027f79303396dba823c2d78c6add83b
> Cr-Commit-Position: refs/heads/master@{#28927}
TBR=arv@chromium.org,caitpotter88@gmail.com,rossberg@chromium.org,yhirano@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=477921
Review URL: https://codereview.chromium.org/1181533006
Cr-Commit-Position: refs/heads/master@{#28928}
Reason for revert:
Test failures: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux64/builds/3829
Original issue's description:
> Promise assimilation fix.
>
> Let x be a fulfilled promise and y be another promise. |x.then(() => y)|
> should call |y.then|, but the current implementation calls PromiseChain.
> We can see the difference when we set a custom function to |y.then|.
>
> This CL fixes the spec violation, but as a result |then| is no longer
> a wrapper of |chain| and in some cases it does not work well with
> |accept| or |chain|. That is not a problem for ES6 promise users because
> ES6 promise doesn't have them.
>
> LOG=N
> BUG=477921
>
> Committed: https://crrev.com/2f57dff3ea0c45e1a61b334fda962460f89d71bc
> Cr-Commit-Position: refs/heads/master@{#28926}
TBR=arv@chromium.org,caitpotter88@gmail.com,rossberg@chromium.org,yhirano@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=477921
Review URL: https://codereview.chromium.org/1176163004
Cr-Commit-Position: refs/heads/master@{#28927}
Let x be a fulfilled promise and y be another promise. |x.then(() => y)|
should call |y.then|, but the current implementation calls PromiseChain.
We can see the difference when we set a custom function to |y.then|.
This CL fixes the spec violation, but as a result |then| is no longer
a wrapper of |chain| and in some cases it does not work well with
|accept| or |chain|. That is not a problem for ES6 promise users because
ES6 promise doesn't have them.
LOG=N
BUG=477921
Review URL: https://codereview.chromium.org/1098663002
Cr-Commit-Position: refs/heads/master@{#28926}
This change rewrites regexps like (ab|ac|z|ad|ae|af) into (a[b-f]|z). We can only reorder disjunctions like this for case-dependent regexps. For case-independent regexps, the disjunctions should be pre-sorted for best results.
R=yangguo@chromium.org
BUG=chromium:482998
LOG=n
Review URL: https://codereview.chromium.org/1180433003
Cr-Commit-Position: refs/heads/master@{#28902}
This deprecates the aforementioned mutator in favor of a simpler
NodeProperties::ReplaceUses that doesn't perform any relaxation.
Preparation for enabling support for try-catch statements.
R=bmeurer@chromium.org
TEST=unittests/NodePropertiesTest
Review URL: https://codereview.chromium.org/1172773003
Cr-Commit-Position: refs/heads/master@{#28897}
Don't DCHECK when neutering that the buffer is not a SharedArrayBuffer;
instead, just return early.
BUG=chromium:498142,chromium:497295
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1174753002
Cr-Commit-Position: refs/heads/master@{#28892}
For top-level code the closure passed into context allocation methods
needs to be replaced with a sentinel to canonicalize is to the empty
function object.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-4169
BUG=v8:4169
LOG=N
Review URL: https://codereview.chromium.org/1172013002
Cr-Commit-Position: refs/heads/master@{#28888}
The initial implementation of this method takes a couple shortcuts:
- At some points in the spec, we should be making a reference to
"Table 49" and instead do property lookup on the constructor.
This is an issue with some other TypedArray methods too.
- The spec indicates that, if constructor and @@species haven't been
messed with in particular ways, then there should be a memcpy
from the old to the new. That fast path is not implemented here
in this patch, but because V8 doesn't canonicalize NaN, the result
isn't observably different.
BUG=v8:3578
LOG=Y
R=arv
Review URL: https://codereview.chromium.org/1170023002
Cr-Commit-Position: refs/heads/master@{#28882}
This adds some basic tests of the interaction between try-catch and
try-finally statements and OSR in TurboFan. The try-osr test suite
follows the structure of try-deopt closely.
R=titzer@chromium.org
TEST=mjsunit/compiler/try-osr
Review URL: https://codereview.chromium.org/1165103003
Cr-Commit-Position: refs/heads/master@{#28855}
This allows try-catch and try-finally constructs to be separately
enabled and disabled. We plan to stage try-catch support soon.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1157863015
Cr-Commit-Position: refs/heads/master@{#28848}
These values were computed by the parser and hence out of sync with any
visitor over the AST. Our AST visitor aborts visitation of statement
lists as soon as a jump statement has been reached. Now handler tables
are guaranteed to be dense and fully populated.
R=ishell@chromium.org
TEST=mjsunit/regress/regress-crbug-493290
BUG=chromium:493290
LOG=N
Review URL: https://codereview.chromium.org/1157213004
Cr-Commit-Position: refs/heads/master@{#28846}
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}
