Previously, arrow function scopes had a separate ScopeType. However,
Scope::DeserializeScopeChain() erroneously deserialized ARROW_SCOPE
ScopeInfos as FUNCTION_SCOPE. This could lead to bugs such as the
attached one, where "super" was disallowed where it should have
been allowed.
This patch utilizes the Scope's FunctionKind to distinguish arrow
functions from others. Besides fixing the above bug, this also
simplifies code in various places that had to deal with two different
ScopeTypes both of which meant "function".
BUG=v8:4466
LOG=n
Review URL: https://codereview.chromium.org/1386253002
Cr-Commit-Position: refs/heads/master@{#31154}
* Promise.resolve is now works with subclasses
* Spec removed [[PromiseConstructor]] now can simply use constructor
* Promise.resolve ignores species
R=littledan@chromium.org,domenic@chromium.org
BUG=v8:4161,v8:4341
LOG=Y
Review URL: https://codereview.chromium.org/1362773002
Cr-Commit-Position: refs/heads/master@{#31116}
Arrow functions have been enabled by default since the 4.5 branch.
Review URL: https://codereview.chromium.org/1373633002
Cr-Commit-Position: refs/heads/master@{#31031}
The actual Function.prototype.toMethod was removed some time already,
but there were some stuff (esp. %ToMethod) left in the tree, including
tests for %ToMethod. This code (and esp. the tests) cause trouble in
the process of moving bound functions away from JSFunction; so since
the code is unused anyway, we can as well remove it.
The original removal of Function.prototype.toMethod was in February
2015 in 68e4897586.
R=jarin@chromium.org
BUG=v8:3330
LOG=n
Review URL: https://codereview.chromium.org/1366063002
Cr-Commit-Position: refs/heads/master@{#30925}
Since https://codereview.chromium.org/366103005 the promise tests null out
various globals, to ensure the promise implementation doesn’t itself rely
on functions patchable by monkeys.
Unfortunately, doing so breaks test assertion failures which rely on
those globals.
This isn’t the ideal solution, but does improve the current state.
R=littledan@chromium.org,domenic@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1370583002
Cr-Commit-Position: refs/heads/master@{#30922}
It's been enabled since M45, which is now well into its stable period,
with no problems reported.
Review URL: https://codereview.chromium.org/1356793002
Cr-Commit-Position: refs/heads/master@{#30835}
Add support for `get` and `set` as shorthand properties. Also
supports them for CoverInitializedName in BindingPatterns and (once implemented)
AssignmentPatterns.
BUG=v8:4412, v8:3584
LOG=N
R=adamk, aperez, wingo, rossberg
Review URL: https://codereview.chromium.org/1328083002
Cr-Commit-Position: refs/heads/master@{#30769}
In certiain cases the ArgumentsIteratorSetter would trigger an invalid
state in the LookupIterator when being overridden. This is now solved
by bypassing the SetDataProperty and directly using
DefinePropertyOrElementIgnoringAttributes since we know exactly which
property we're going to install
LOG=N
BUG=chromium:521484
Review URL: https://codereview.chromium.org/1332873002
Cr-Commit-Position: refs/heads/master@{#30705}
Make ObjectLiteral::is_simple() false for literals containing computed
property names, which causes IsCompileTimeValue() to return false and
thus force code to be generated for setting up such properties. This
mirrors the handling of '__proto__' in literals.
BUG=v8:4387
LOG=y
Review URL: https://codereview.chromium.org/1307943007
Cr-Commit-Position: refs/heads/master@{#30362}
The ES6 spec for this function declares that ToLength
should only be called once. We were evaluating it multiple
times, so if length was an object with a valueOf method,
we could see effects take place multiple times.
R=littledan@chromium.org
LOG=N
BUG=v8:4218
Review URL: https://codereview.chromium.org/1237583005
Cr-Commit-Position: refs/heads/master@{#30240}
This patch strengthens testing of classes by verifying that the binding
that they export externally follows block scoping, as opposed to var-style
scoping. The tests are based on existing tests for let and const.
R=adamk
LOG=N
BUG=v8:3305
Review URL: https://codereview.chromium.org/1286923002
Cr-Commit-Position: refs/heads/master@{#30140}
To avoid tanking context startup performance, only the actual installation of the
JS-exposed API is flag-guarded. The remainder of the implementation still
resides in the snapshot.
Review URL: https://codereview.chromium.org/1257063003
Cr-Commit-Position: refs/heads/master@{#30017}
While at it, remove the notion of INTERNAL variables.
@caitp: Took some parts from your CL, since I was blocked on the temp scope bug.
R=mstarzinger@chromium.org
BUG=512574
LOG=N
Review URL: https://codereview.chromium.org/1250513004
Cr-Commit-Position: refs/heads/master@{#29812}
Many mjsunit tests (as well as the promises-aplus adapter scripts) were
using Object.observe simply for microtask-enqueueing purposes. Replaced
such uses with %EnqueueMicrotask.
Review URL: https://codereview.chromium.org/1246933002
Cr-Commit-Position: refs/heads/master@{#29779}
- Test that TypedArray properties cannot be set in strict mode
Properties like %TypedArray%.prototype.length have a getter and no
setter. This test verifies that property, which was apparently not
true in the past or had no test ensuring throwing in this case.
- Test that TypedArray integer indexed properties (array elements)
are not configurable
Both of these have passed for some time, but there are open bugs against
them and apparently no tests verifying that they are fixed.
BUG=v8:3048, v8:3799
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1232843005
Cr-Commit-Position: refs/heads/master@{#29717}
This is a change from ES5 to ES6: When reversing an array, first it is checked
whether the element exists, before the element is looked up. The order in ES6
is
[[HasElement]] lower
[[Get]] lower (if present)
[[HasElement]] upper
[[Get]] upper (if present)
In ES5, on the other hand, the order was
[[Get]] lower
[[Get]] upper
[[HasElement]] lower
[[HasElement]] upper
To mitigate the performance impact, this patch implements a new, third copy
of reversing arrays if %_HasPackedElements. This allows us to skip all
membership tests, and a quick and dirty benchmark shows that the new version
is faster:
Over 4 runs, the slowest for the new version:
d8> var start = Date.now(); for (var i = 0; i < 100000000; i++) [1, 2, 3, 4, 5].reverse(); Date.now() - start
4658
Over 3 runs, the fastest for the old version:
d8> var start = Date.now(); for (var i = 0; i < 100000000; i++) [1, 2, 3, 4, 5].reverse(); Date.now() - start
5176
BUG=v8:4223
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1238593003
Cr-Commit-Position: refs/heads/master@{#29716}
Conditionally including Array and TypedArray methods seems to cause
a slowdown in V8 context creation, possibly due to the new code added.
BUG=chromium:504629
R=adamk@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1215863003
Cr-Commit-Position: refs/heads/master@{#29430}
The enumerable expression in a for-in/of loop is supposed to have a TDZ for any
lexically bound names in that loop (there can be more than one with destructuring).
This patch accomplishes this with an almost-correct desugaring. The only thing missing
is proper debugger support (the let declarations added by the desugaring, while invisible
to code due to shadowing, are visible to the debugger).
BUG=v8:4210
LOG=n
Review URL: https://codereview.chromium.org/1218543003
Cr-Commit-Position: refs/heads/master@{#29396}
Before this we were using String.prototype.replace. Now
we call the internal StringReplace instead.
BUG=v8:4221
LOG=N
R=adamk, littledan
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1199933005
Cr-Commit-Position: refs/heads/master@{#29206}
Before this we were using + which calls valueOf which is not correct
for these methods.
BUG=v8:4222
LOG=N
R=adamk, littledan
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1194173004
Cr-Commit-Position: refs/heads/master@{#29202}
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}
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 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}
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 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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
ES6 specs the function length property (it was not part of ES5) and
it makes it configurable.
BUG=v8:3045
LOG=N
R=mstarzinger@chromium.org, adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/993073002
Cr-Commit-Position: refs/heads/master@{#27190}
Function name property is now standardized in ES6. It was a Mozilla proprietary
extension before. With ES6, the property was made configurable, so that it can
be used instead of another proprietary property, displayName.
This is a revert of revert c791d84112.
Last time this broke a Chrome browser test which has since been updated:
5f75a3be4c
BUG=v8:3333
LOG=N
R=mstarzinger@chromium.org,verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/977003004
Cr-Commit-Position: refs/heads/master@{#26996}
This is partially based on r21609 but that CL was incomplete.
Function name is still non writable so one has to use defineProperty
to change the actual value.
BUG=v8:3333
LOG=N
R=adamk, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/960343002
Cr-Commit-Position: refs/heads/master@{#26924}
