This switches all remaining builtin methods to use the ES6 new.target
value when determined whether being called as a constructor or not. This
is prepatory work for fully deprecating the aforementioned intrinsic.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1474343002
Cr-Commit-Position: refs/heads/master@{#32447}
This fixes a corner-case in redeclaration handling, where the ES2015
early error case got mixed up with legacy const handling in the parser.
Redeclaration using ES2015 'let' and 'const' should be early errors,
but legacy 'const' redeclaration has historically been a runtime error,
and should stay that way until legacy 'const' is gone.
The fix here is uglier than it might be due to
https://code.google.com/p/v8/issues/detail?id=4577, which keeps us
from simplifying the mess of if/else-if in the current code.
BUG=v8:4576
LOG=n
Review URL: https://codereview.chromium.org/1485943002
Cr-Commit-Position: refs/heads/master@{#32429}
Both are integrated into JSReceiver::GetKeys().
For now, the implementation ignores Symbol/DONT_ENUM filtering.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1474083003
Cr-Commit-Position: refs/heads/master@{#32384}
This makes sure that proxy + Function/Array works
Makes sure that new.target can be a generator
Makes sure that if new.target is not a subclass, but does not have a prototype, that we'll get that same prototype back the next time we look at new.target.prototype.
BUG=v8:1543, v8:3330, v8:3931
LOG=n
Review URL: https://codereview.chromium.org/1484473002
Cr-Commit-Position: refs/heads/master@{#32382}
This replaces internal GetConstructorName with toStringTag, .constructor's name
and class_name. This entirely changes how the name is computed for use in
devtools.
BUG=chromium:529177
LOG=n
Review URL: https://codereview.chromium.org/1435273002
Cr-Commit-Position: refs/heads/master@{#32374}
The fast-prototype test has been outsmarted by constructor inlining
because the instantiation is been correctly optimized away. Internal
state introspection about prototype turning fast was upset by that.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1474763007
Cr-Commit-Position: refs/heads/master@{#32338}
Up until now we sometimes pass Smi 0 around as closure and expect the
runtime to translate that appropriately. But we need to be careful in
some places to not confuse the Smi 0 with a real closure. However, we
could instead just pass the correct closure extracted from the native
context.
This addresses three long-standing TODOs in the JSTypedLowering pass.
Drive-by-fix: Further unify error message reporting for ToObject (we had
a special message in case of ToObject error in with context creation).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1475383002
Cr-Commit-Position: refs/heads/master@{#32336}
Reason for revert:
This is also unsound for the reasons outlined in
https://codereview.chromium.org/1473073004/
Will reland the mjsunit test separately and help Fedor to implement a solution based on simplified operators.
Original issue's description:
> [machine-operator-reducer] fix float truncation
>
> Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
> `value`. Generally, `value` may have a range bigger than the one that
> could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
> instead, and only if the `value` fits into Float64 without precision
> loss.
>
> Add missing mjsunit test for 52bit multiplication/division optimization
> that has landed in refs/heads/master@{#31899}.
>
> BUG=
> R=titzer@google.com
>
> Committed: https://crrev.com/64efa2a904773816968992628f0bf0f1b7ae82be
> Cr-Commit-Position: refs/heads/master@{#32227}
TBR=titzer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1468313009
Cr-Commit-Position: refs/heads/master@{#32312}
ES6 section 12.2.8.1 states that flags for regular expression literals
must be checked during parsing and invalid flags are early errors. This
change adapts the Scanner and (Pre)Parser to act according to the spec.
This is also a prerequisite to unify the handling of literal creation
(for Objects, Arrays, Regexps, and at some point Classes).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1472323002
Cr-Commit-Position: refs/heads/master@{#32273}
Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
`value`. Generally, `value` may have a range bigger than the one that
could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
instead, and only if the `value` fits into Float64 without precision
loss.
Add missing mjsunit test for 52bit multiplication/division optimization
that has landed in refs/heads/master@{#31899}.
BUG=
R=titzer@google.com
Review URL: https://codereview.chromium.org/1433353006
Cr-Commit-Position: refs/heads/master@{#32227}
This patch removes Promise functions and methods which are absent
from the ES2015 specification when the --es-staging flag is on.
BUG=v8:3237
R=rossberg
LOG=Y
Review URL: https://codereview.chromium.org/1469543003
Cr-Commit-Position: refs/heads/master@{#32194}
In a function expression, 'yield' is allowed, even if the expression
occurs inside a generator. Similarly, even in a non-generator,
a generator expression's name must not be 'yield'.
BUG=v8:3983
LOG=n
Review URL: https://codereview.chromium.org/1460393003
Cr-Commit-Position: refs/heads/master@{#32188}
We currently assume that all prototype maps are stable, which is
not guaranteed for certain keyed access patterns. So we explicitly
disallow optimizing the element access there for now.
BUG=chromium:557807, v8:4470
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1456973004
Cr-Commit-Position: refs/heads/master@{#32101}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
When adding properties to the result object, that object's prototype chain should be ignored.
Review URL: https://codereview.chromium.org/1458873002
Cr-Commit-Position: refs/heads/master@{#32085}
This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread
Review URL: https://codereview.chromium.org/1455953002
Cr-Commit-Position: refs/heads/master@{#32079}
If the input type does not help us, we are conservative and truncate (rather than guessing signed).
Review URL: https://codereview.chromium.org/1455103002
Cr-Commit-Position: refs/heads/master@{#32075}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1453733002
Cr-Commit-Position: refs/heads/master@{#32050}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1452193003
Cr-Commit-Position: refs/heads/master@{#32048}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1451423002
Cr-Commit-Position: refs/heads/master@{#32047}
Several changes are included here:
1. Each resolution callback references shared data indicating whether
it has already been resolved or not, as described in 25.4.1.3
http://tc39.github.io/ecma262/#sec-createresolvingfunctions.
Previously this was handled exclusively by the Promise's status,
which does not work correctly with the current chaining behaviour.
2. During fulfillment, When a Promise is resolved with a thenable, the
spec chains the promises together by invoking the thenable's `then`
function with the original Promise's resolve and reject methods (per
section 25.4.2.2, or
http://tc39.github.io/ecma262/#sec-promiseresolvethenablejob, on the
next tick, regardless of whether or not there are pending tasks.
3. Adds a spec compliance fix to ensure that the Promise constructor
is only loaded once when `then()` is called, solving v8:4539 as well.
This involves refactoring PromiseChain to accept a constructor
argument. PromiseChain/PromiseDeferred will hopefully be removed soon,
simplifying the process.
BUG=v8:4162, v8:4539, v8:3237
LOG=N
R=rossberg@chromium.org, littledan@chromium.org, adamk@chromium.org
Review URL: https://codereview.chromium.org/1394463003
Cr-Commit-Position: refs/heads/master@{#32046}
The previous code did not properly check for harmony const when
doing the dynamic redeclaration check. This was masked in the
test because each eval had an initializer, and the initializer was what
triggered the exception.
This patch tightens the test by removing initializers and fixes the bug in
DeclareLookupSlot.
Also change the test to use assertThrows where possible.
BUG=v8:4550
LOG=n
Review URL: https://codereview.chromium.org/1437003006
Cr-Commit-Position: refs/heads/master@{#31995}
* Limit triggering of tail calls to explicit use of a new inline runtime
function %_TailCall. %_TailCall works just like %_Call except for using
tail-calling mechanics (currently only in TF).
* Remove hack that recognized some specific usages of %_Call and converted them
into tail calls.
* Support tail calls for all calls where the number of callee stack parameters
is less than or equal to the number of caller stack parameters.
* Use the gap resolver to swizzle parameters and registers to tail calls.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1439613003
Cr-Commit-Position: refs/heads/master@{#31987}
With do-expressions any expression used as a case label can turn into an
OSR entry-point. This means the value being switched over is renamed to
an OSR value and needs to be reloaded from the environment at each case.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-case-label
Review URL: https://codereview.chromium.org/1438123007
Cr-Commit-Position: refs/heads/master@{#31986}
This makes sure that inlining a constructor call to a function which
cannot be used as a constructor (e.g. strong mode function) still does
throw correctly when the implicit receiver is created.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-inline-strong-as-construct
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1447443002
Cr-Commit-Position: refs/heads/master@{#31982}
This implements a first version of support for constructor call inlining
in the inlining machinery. For now we can only inline calls where the
actual constructor and the original constructor coincide (i.e. no super
constructor calls). Note that the target of a super constructor call is
loaded with a runtime call, so there is no way for it to be constant
promoted at the moment.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1435873002
Cr-Commit-Position: refs/heads/master@{#31954}
RegExp.prototye[@@split] is not yet implement to spec regarding creating
new RegExp object with the SpeciesConstructor.
R=littledan@chromium.org
BUG=v8:4345
LOG=N
Review URL: https://codereview.chromium.org/1427573005
Cr-Commit-Position: refs/heads/master@{#31911}
Reason for revert: failed tests on a Windows build.
TBR=rossberg,cbruni,neis
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1426943007
Cr-Commit-Position: refs/heads/master@{#31907}
Remove some non-standard code that doesn't do anything anyways.
While FireFox uses this to set the default value for the multiline flag,
it is nonstandard and slated for removal. The matching behaviour has
never been implemented in either JSC or V8, so there is little
web-compat risk.
The only possible risk could be someone depending on the ToBoolean()
behaviour of the flag, but this seems unlikely.
BUG=v8:3870
LOG=N
R=adamk@chromium.org, littledan@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1417733012
Cr-Commit-Position: refs/heads/master@{#31882}
JSRegExp's properties backing stores must not be shared.
BUG=chromium:548580
LOG=N
Review URL: https://codereview.chromium.org/1429743006
Cr-Commit-Position: refs/heads/master@{#31867}
Adds a blacklist of tests which are currently unsupported or broken in Ignition to
the mjsunit and test262 test status.
Also removes --ignition-script-filter flag, and adds a
--ignition_fallback_on_eval_and_catch flag which fallsback to fullcodegen for
functions which call eval or contain a catch block.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1420963009
Cr-Commit-Position: refs/heads/master@{#31864}
We forgot to add the number of arguments parameter in
JSFrameSpecialization, which was added before the context.
R=jarin@chromium.org
BUG=chromium:552304
LOG=n
Review URL: https://codereview.chromium.org/1429233004
Cr-Commit-Position: refs/heads/master@{#31856}
This fixes receiver conversion since the Call builtin does it correctly.
BUG=v8:4526
LOG=n
Review URL: https://codereview.chromium.org/1407373007
Cr-Commit-Position: refs/heads/master@{#31823}
The %_CallFunction doesn't implement the call sequence properly, it
doesn't do the receiver wrapping, nor does it check for
classConstructor. Also the eager deoptimization for %_CallFunction was
seriously b0rked (we must have been lucky with TurboFan so far).
R=yangguo@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1419813010
Cr-Commit-Position: refs/heads/master@{#31821}
Fix an earlier regression which forbid non-VariableProxy LHS from being
used in for-of loops. Like for-in loops, the spec allows any LHS to be used,
with the sole exception that ObjectLiterals and ArrayLiterals must be valid
AssignmentPatterns.
Also fixes a bug in TurboFan which resulted in incorrectly replacing a variable load with a constant value in some instances, due to the AstLoopAssignmentAnalyzer failing to record the assignment to ForOfStatement's value.
BUG=v8:4418, v8:2720
LOG=N
R=wingo@igalia.com, littledan@chromium.org, adamk@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1411873004
Cr-Commit-Position: refs/heads/master@{#31816}
This patch moves ES2015 ToLength semantics on array operations, etc
to from staging to shipping.
R=adamk
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1433473003
Cr-Commit-Position: refs/heads/master@{#31810}
Reason for revert:
MSAN errors on arm64: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/5123/
Original issue's description:
> [es6] Implement destructuring binding in try/catch
>
> The approach is to desugar
>
> try { ... }
> catch ({x, y}) { ... }
>
> into
>
> try { ... }
> catch (.catch) {
> let x = .catch.x;
> let y = .catch.y;
> ...
> }
>
> using the PatternRewriter's normal facilities. This has the side benefit
> of throwing the appropriate variable conflict errors for declarations
> made inside the catch block.
>
> No change is made to non-destructured cases, which will hopefully save
> us some work if https://github.com/tc39/ecma262/issues/150 is adopted
> in the spec.
>
> There's one big problem with this patch, which is a lack of PreParser
> support for the redeclaration errors. But it seems we're already lacking
> good PreParser support for such errors, so I'm not sure that should
> block this moving forward.
>
> BUG=v8:811
> LOG=y
>
> Committed: https://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba
> Cr-Commit-Position: refs/heads/master@{#31797}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811
Review URL: https://codereview.chromium.org/1408063013
Cr-Commit-Position: refs/heads/master@{#31798}
The approach is to desugar
try { ... }
catch ({x, y}) { ... }
into
try { ... }
catch (.catch) {
let x = .catch.x;
let y = .catch.y;
...
}
using the PatternRewriter's normal facilities. This has the side benefit
of throwing the appropriate variable conflict errors for declarations
made inside the catch block.
No change is made to non-destructured cases, which will hopefully save
us some work if https://github.com/tc39/ecma262/issues/150 is adopted
in the spec.
There's one big problem with this patch, which is a lack of PreParser
support for the redeclaration errors. But it seems we're already lacking
good PreParser support for such errors, so I'm not sure that should
block this moving forward.
BUG=v8:811
LOG=y
Review URL: https://codereview.chromium.org/1417483014
Cr-Commit-Position: refs/heads/master@{#31797}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
Cr-Commit-Position: refs/heads/master@{#31786}
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31790}
Reason for revert:
failing build bot
Original issue's description:
> [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
>
> The current implementation of classes throws the TypeError at the wrong
> point, after activating a new context when directly calling a class
> constructor. According to the spec, the TypeError has to be thrown
> in the caller context.
>
> LOG=N
> BUG=v8:4428
>
> Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
> Cr-Commit-Position: refs/heads/master@{#31786}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4428
Review URL: https://codereview.chromium.org/1415783006
Cr-Commit-Position: refs/heads/master@{#31787}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31786}
This removes special casing for the 'f.arguments' property accessor. Any
local 'arguments' variable should not be allowed to influence the value
returned by the indirect 'f.arguments' property. That property creates a
new object with a separate identity everytime it is read. This is by now
consistent with other browsers.
R=rossberg@chromium.org
TEST=mjsunit/arguments-indirect
Review URL: https://codereview.chromium.org/1408983006
Cr-Commit-Position: refs/heads/master@{#31776}
Original issue's description:
> [es6] Fix Function and GeneratorFunction built-ins subclassing.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/99e7f872d3d0a5fb799dcbafb05537cda491314a
> Cr-Commit-Position: refs/heads/master@{#31708}
The problem was in another CL, this is a clean reland with improved tests.
BUG=v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1415683007
Cr-Commit-Position: refs/heads/master@{#31756}
If the property is a data property on the holder (or does not exist) and is a readonly data property in the receiver, then we must fail.
R=rossberg, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1424233005
Cr-Commit-Position: refs/heads/master@{#31751}
1) The Map::CopyInitialMap() did not set descriptor's array if
the source initial map had one.
2) Subclasses are temporarily disallowed to have more in-object
properties than the parent class (for GC reasons).
BUG=v8:3101, v8:3330, v8:4531
LOG=N
Review URL: https://codereview.chromium.org/1431593003
Cr-Commit-Position: refs/heads/master@{#31743}
TurboFan is actually able to generate property access to all prototypes
of all primitives, except the special Oddball primitives that have no
wrapper counterparts (namely null and undefined from the ES6 point of
view).
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1409163007
Cr-Commit-Position: refs/heads/master@{#31739}
Original issue's description:
> [es6] Better support for built-ins subclassing.
>
> Create proper initial map for original constructor (new.target) instead of doing prototype
> transition on the base constructor's initial map. This approach fixes in-object slack tracking
> for subclass instances.
> This CL also fixes subclassing from String.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/cd5f48302a502154a0106d12e3066bd563c6340c
> Cr-Commit-Position: refs/heads/master@{#31680}
It also fixes typed array map smashing done during typed array initialization.
BUG=v8:3101, v8:3330, v8:4419
LOG=Y
Review URL: https://codereview.chromium.org/1413033006
Cr-Commit-Position: refs/heads/master@{#31701}
Create proper initial map for original constructor (new.target) instead of doing prototype transition on the base constructor's initial map. This approach fixes in-object slack tracking for subclass instances.
This CL also fixes subclassing from String.
BUG=v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1427483002
Cr-Commit-Position: refs/heads/master@{#31680}
Reason for revert:
[Sheriff] Causes layout test failures.
Original issue's description:
> Remove RegExp.multiline accessors.
>
> This is non-standard and not even documented on MDN.
>
> On Firefox, setting RegExp.multiline to true adds the multiline flag to all
> newly created RegExp objects (both from constructor and from literal).
>
> In V8 this has no effect.
>
> Source archaelogy shows that this is from the initial commit.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/e8f752ce0c2a488e88cd87fe75f3907b4303d0a0
> Cr-Commit-Position: refs/heads/master@{#31673}
TBR=bmeurer@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1431433004
Cr-Commit-Position: refs/heads/master@{#31679}
This is non-standard and not even documented on MDN.
On Firefox, setting RegExp.multiline to true adds the multiline flag to all
newly created RegExp objects (both from constructor and from literal).
In V8 this has no effect.
Source archaelogy shows that this is from the initial commit.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1410993008
Cr-Commit-Position: refs/heads/master@{#31673}
This fixes [NAMED|KEYED]_SUPER_PROPERTY_CALL to perform a method call
instead of a function call. The difference is visible for sloppy mode
targets that convert primitive receivers.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4525
BUG=v8:4525
LOG=n
Review URL: https://codereview.chromium.org/1419173004
Cr-Commit-Position: refs/heads/master@{#31664}
This requires copying usage flags from the outer scope to the
arrow scope upon encountering the arrow token.
In order to properly pass-on the calls_eval bit, now record
that bit on script scopes just like everywhere else, and add
necessary code to scopes.cc to handle that change in behavior.
Also factored out scope flag propagation to its own method to
make the call site simple (though note that only the eval
bit makes any difference for arrows).
BUG=v8:4395
LOG=n
Review URL: https://codereview.chromium.org/1423613002
Cr-Commit-Position: refs/heads/master@{#31660}
The fix is to broaden the set of cases for when NeedsHomeObject()
returns true. Note that this is broader than it needs to be (since,
e.g., non-arrow function scopes inside a method can't reference
super). But we don't track the types of inner scopes at the moment,
so this is the best we can do.
R=rossberg@chromium.org
BUG=v8:4522
LOG=n
Review URL: https://codereview.chromium.org/1411093008
Cr-Commit-Position: refs/heads/master@{#31659}
This refactors the handling of calls of type Call::PROPERTY_CALL to
super properties in AstGraphBuilder::VisitCall. It ensures that the
operand stack is kept in sync with full-codegen so that deopts while
evaluating sub-expressions behave as expected.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4521
BUG=v8:4521
LOG=n
Review URL: https://codereview.chromium.org/1426893003
Cr-Commit-Position: refs/heads/master@{#31652}
When == is invoked on a Symbol or SIMD vector and an object, the object should
be converted to a primitive with ToPrimitive and then compared again. This means,
for example, that for a Symbol or SIMD vector s, s == Object(s). This patch makes
that change in the implementation of ==. Only the runtime function needed to be
changed, as the code stubs and compiler specializations don't operate on Symbols
or SIMD vectors, and on these types, a fallback to the runtime function is always
used.
BUG=v8:3593
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1421413002
Cr-Commit-Position: refs/heads/master@{#31614}
This fixes a missing SSA-renaming of the callee value used in the frame
state of a call node. An OSR-entry within do-expressions contained in
one of the argument expression can trigger that renaming.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-crbug-546968
BUG=chromium:546968
LOG=n
Review URL: https://codereview.chromium.org/1430483002
Cr-Commit-Position: refs/heads/master@{#31613}
Reason for revert:
The test failure was unrelated; relanding.
Original issue's description:
> Revert of Check that array length stays a safe integer in Array.prototype.push (patchset #7 id:120001 of https://codereview.chromium.org/1428483002/ )
>
> Reason for revert:
> Caused for-in-opt test to fail
>
> Original issue's description:
> > Check that array length stays a safe integer in Array.prototype.push
> >
> > This patch adds a check in Array.prototype.push to assert that the new
> > length does not become greater than 2**53-1. Such a length would be
> > dangerous because integer arithmetic becomes imprecise after the
> > boundary. The check is also required by a test262 test.
> >
> > R=adamk
> > LOG=Y
> > BUG=v8:3087
> >
> > Committed: https://crrev.com/e68adf4548dd101dc08fcbff14444152fb1b7fe7
> > Cr-Commit-Position: refs/heads/master@{#31588}
>
> TBR=adamk@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:3087
>
> Committed: https://crrev.com/78abedb94431a233842fcb2f7a910805a05bed09
> Cr-Commit-Position: refs/heads/master@{#31590}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3087
Review URL: https://codereview.chromium.org/1424823005
Cr-Commit-Position: refs/heads/master@{#31610}
Previously ChangeLowering would always box float64 values when going to
tagged representation, but that introduces a lot of deoptimizer loops
and polymorphism into TurboFan, which is unfortunate and unnecessary.
This adds some logic to ChangeFloat64ToTagged to try harder to create a
Smi when going from Float64 to Tagged, instead of always allocating a
HeapNumber. This might need some additional tweaking, but at least it
makes it possible to start comparing TurboFan and Crankshaft for some
regular JavaScript.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1420913003
Cr-Commit-Position: refs/heads/master@{#31609}
Full-codegen prepared for the bailout in the wrong place, causing side
effects to be replayed when they shouldn't. Crankshaft and Turbofan are
in agreement about where the deopt should jump to.
TEST=mjsunit/for-in-opt
R=jarin@chromium.org
BUG=v8:4381
LOG=y
Review URL: https://codereview.chromium.org/1413923005
Cr-Commit-Position: refs/heads/master@{#31607}
This introduces a JSConvertReceiver operator to model the implicit
conversion of receiver values for sloppy callees. It is used by the
JSInliner for now, but can also be used to model direction function
calls that bypass call stubs.
Also note that a hint is passed to said operator whenever the source
structure constrains the receiver value type. This hint allows for
optimizations in the lowering of the operator.
The underlying specification in ES6, section 9.2.1.2 is the basis for
this implementation.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/receiver-conversion
BUG=v8:4493, v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1412223015
Cr-Commit-Position: refs/heads/master@{#31598}
With ES6 21.2.5.8, step 13, we no longer have to keep up the illusion
that matching and calling replace function is interleaved. This is
observable through unspec'ed static properties such as RegExp.$1.
Last match info not working yet.
R=littledan@chromium.org
Review URL: https://codereview.chromium.org/1418703003
Cr-Commit-Position: refs/heads/master@{#31593}
Reason for revert:
Caused for-in-opt test to fail
Original issue's description:
> Check that array length stays a safe integer in Array.prototype.push
>
> This patch adds a check in Array.prototype.push to assert that the new
> length does not become greater than 2**53-1. Such a length would be
> dangerous because integer arithmetic becomes imprecise after the
> boundary. The check is also required by a test262 test.
>
> R=adamk
> LOG=Y
> BUG=v8:3087
>
> Committed: https://crrev.com/e68adf4548dd101dc08fcbff14444152fb1b7fe7
> Cr-Commit-Position: refs/heads/master@{#31588}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3087
Review URL: https://codereview.chromium.org/1418093007
Cr-Commit-Position: refs/heads/master@{#31590}
This patch adds a check in Array.prototype.push to assert that the new
length does not become greater than 2**53-1. Such a length would be
dangerous because integer arithmetic becomes imprecise after the
boundary. The check is also required by a test262 test.
R=adamk
LOG=Y
BUG=v8:3087
Review URL: https://codereview.chromium.org/1428483002
Cr-Commit-Position: refs/heads/master@{#31588}
This fixes the representation type for values in JSArray::length fields
when JSNativeContextSpecialization lowers loads. Only arrays with fast
elements kind are guaranteed to have a Smi represented length.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-4515
BUG=v8:4515, v8:4493, v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1410393006
Cr-Commit-Position: refs/heads/master@{#31558}
The reason is when native_context_specialization flag is ture, X87 turbofan
will hit the known issue that X87 will change a sNaN to qNaN by default. And
then it will fail when bit-comparing the source (sNaN) and the result (qNaN).
reland https://codereview.chromium.org/1414733004/.
BUG=
Review URL: https://codereview.chromium.org/1419573007
Cr-Commit-Position: refs/heads/master@{#31552}
Reason for revert:
because of merge mistake, "regress/" is missed when skipping one test case for X87.
"regress/" will be added when relanding it.
Original issue's description:
> X87: disable the regress-undefined-nan test case for x87.
>
> The reason is when native_context_specialization flag is ture, X87 turbofan
> will hit the known issue that X87 will change a sNaN to qNaN by default. And
> then it will fail when bit-comparing the source (sNaN) and the result (qNaN).
>
> BUG=
>
> Committed: https://crrev.com/b3c719ebbad6c87afefa33a7d0b3f412b2e304db
> Cr-Commit-Position: refs/heads/master@{#31530}
TBR=bmeurer@chromium.org,weiliang.lin@intel.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1417303005
Cr-Commit-Position: refs/heads/master@{#31543}
For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.
BUG=546967, v8:4488
LOG=N
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1414713004
Cr-Commit-Position: refs/heads/master@{#31537}
The reason is when native_context_specialization flag is ture, X87 turbofan
will hit the known issue that X87 will change a sNaN to qNaN by default. And
then it will fail when bit-comparing the source (sNaN) and the result (qNaN).
BUG=
Review URL: https://codereview.chromium.org/1414733004
Cr-Commit-Position: refs/heads/master@{#31530}
This patch only treats non-private symbols as valid feedback, thus
avoiding the need to switch to Oddballs for the feedback sentinels
and avoiding breaking the use of private own symbols.
Crankshaft will also optimize these symbol loads into a named load,
just as it does for string keyed loads with type feedback.
BUG=
Review URL: https://codereview.chromium.org/1415333003
Cr-Commit-Position: refs/heads/master@{#31496}
The newly introduced root makes sure that we do not flush the
optimized code while the function is being compiled.
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1415133002
Cr-Commit-Position: refs/heads/master@{#31444}
This makes sure that initializing assignments of let-declared variables
perform an environment lookup and hence keep the variable alive. This is
needed because full-codegen contains debug code verifying the variable
is still inside the TDZ at the initializing assignment.
R=jarin@chromium.org
TEST=mjsunit/compiler/regress-variable-liveness-let
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1420573002
Cr-Commit-Position: refs/heads/master@{#31437}
When eagerly parsing arrow functions, expressions in default
parameter initializers are parsed in the enclosing scope,
rather than in the function's scope (since that scope does not
yet exist). This leads to VariableProxies being added to the
wrong scope, and scope chains for FunctionLiterals being incorrect.
This patch addresses these problems by adding a subclass of
AstExpressionVisitor that moves VariableProxies to the proper
scope and fixes up scope chains of FunctionLiterals.
This is a revert of the revert https://crrev.com/e41614a058426fb6102e4ab2dd4f98997f00c0fc
with a much-improved (though not yet perfect) Scope::ResetOuterScope
method which properly fixes not only the outer_scope_ pointer but also
fixes the inner_scope_ list in the relevant outer_scopes.
More work likely still needs to be done to make this work completely,
but it's very close to correct.
BUG=v8:4395
LOG=y
Review URL: https://codereview.chromium.org/1414283002
Cr-Commit-Position: refs/heads/master@{#31435}
It is not always safe to allocate new heap objects in the JSGraph. We
might have to revisit this later once we do the canonicalization for
HeapConstants.
R=jarin@chromium.org
BUG=chromium:545364
LOG=n
Review URL: https://codereview.chromium.org/1413373002
Cr-Commit-Position: refs/heads/master@{#31421}
The problem is that the gc pattern is different, and the list of debug scripts
may have more or less duplicates than before. The solution is to just turn off
--stress-opt for the test.
R=yangguo@chromium.org
BUG=v8:4502
LOG=N
Review URL: https://codereview.chromium.org/1416883002
Cr-Commit-Position: refs/heads/master@{#31415}
Use the simple inline function version of {Min, Max} where possible to
improve performance
Now uses an forced inline js function instead of a python macro
to avoid expressions be evaluated twice
Follow-up to CR: https://codereview.chromium.org/1331993004
Review URL: https://codereview.chromium.org/1410473002
Cr-Commit-Position: refs/heads/master@{#31411}
This stages the general purpose inlining mechanism in TurboFan and
also disables the remaining tests that still fail. We do this to get
test coverage early and to avoid regressing inlining as we go along.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1419623002
Cr-Commit-Position: refs/heads/master@{#31406}
Reason for revert:
Breaks nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%202/builds/2407/steps/Check/logs/regress-4395
Original issue's description:
> [es6] Fix scoping for default parameters in arrow functions
>
> When eagerly parsing arrow functions, expressions in default
> parameter initializers are parsed in the enclosing scope,
> rather than in the function's scope (since that scope does not
> yet exist). This leads to VariableProxies being added to the
> wrong scope, and scope chains for FunctionLiterals being incorrect.
>
> This patch addresses these problems by adding a subclass of
> AstExpressionVisitor that moves VariableProxies to the proper
> scope and fixes up scope chains of FunctionLiterals.
>
> More work likely still needs to be done to make this work completely,
> but it's very close to correct.
>
> BUG=v8:4395
> LOG=y
>
> Committed: https://crrev.com/cf72aad39e51de9b7074ea039377c1812f4a2c6b
> Cr-Commit-Position: refs/heads/master@{#31402}
TBR=rossberg@chromium.org,caitpotter88@gmail.com,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4395
Review URL: https://codereview.chromium.org/1417463004
Cr-Commit-Position: refs/heads/master@{#31404}
This patch refactors array methods to have the
InnerArray{Map,Filter} methods convert to a GlobalArray
rather than the callers.
BUG=chromium:544991
R=yangguo,adamk
CC=mstarzinger,jochen
LOG=Y
Review URL: https://codereview.chromium.org/1408213004
Cr-Commit-Position: refs/heads/master@{#31403}
