As far as I can see, we have had this bug as long as destructuring assignments
have been there (i.e., this is not regression).
The problem was that Parser::DoParseFunction parsed the arrow function parameters
but didn't rewrite the destructuring assignments in them.
BUG=chromium:704811
Change-Id: I0b1424e7d5103eda6efd51b403fe81a4ee235e01
Reviewed-on: https://chromium-review.googlesource.com/459618
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44177}
This reverts commit 6ad5ca59c9.
Reason for revert: Breaks on noi18n bot, needs fix in the new regression test
Original change's description:
> [wasm] Check the result of Promise::Resolver
>
> We check that if we do not get a result, or if we get a negative result,
> then there has to be a scheduled exception.
>
> R=clemensh@chromium.org
> TEST=mjsunit/regress/wasm/regression-704127
> BUG=chromium:704127
>
> Change-Id: I3fef3cc02f685a9cbc3f10203e2a59b61b3702d5
> Reviewed-on: https://chromium-review.googlesource.com/458282
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44144}
TBR=ahaas@chromium.org,clemensh@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:704127
Change-Id: Ibf6d27929c88064bc2755688358998640092e31a
Reviewed-on: https://chromium-review.googlesource.com/459512
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44145}
We check that if we do not get a result, or if we get a negative result,
then there has to be a scheduled exception.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regression-704127
BUG=chromium:704127
Change-Id: I3fef3cc02f685a9cbc3f10203e2a59b61b3702d5
Reviewed-on: https://chromium-review.googlesource.com/458282
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44144}
Since we no longer support the ignition-staging configuration
any longer, we can retire the three tier pipeline and the
CompileBaseline functionallity.
We still need support for JSFunction self healing due to
liveedit (which for --no-turbo might end up replacing a
forced Ignition function with a FCG function) - we can
remove this once we remove --no-turbo support.
BUG=v8:4280
Change-Id: I5482abd17785324654e022affd6bdb555b19b181
Reviewed-on: https://chromium-review.googlesource.com/452620
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44141}
The stack check at the beginning of each function maps to the wasm byte
offset 0. For asm.js functions, this byte offset is mapped further to an
asm.js source position. For most functions, we explicitly add an entry
to this side table for offset 0. This was missing for the start
function.
R=ahaas@chromium.org
BUG=v8:4203,chromium:703568
Change-Id: I05bc4a8cfa666864bb7a0b23f75186abe0be9bee
Reviewed-on: https://chromium-review.googlesource.com/458437
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44037}
This fixes a corner case where the "instance prototype" diverges from
the "non-instance prototype" that we store on the initial map of a
constructor function.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-703610
BUG=chromium:703610
Change-Id: I30a19ae621e10b512215ffb191ce00d030941440
Reviewed-on: https://chromium-review.googlesource.com/458396
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44008}
This fixes a bug where an exported function is being specialized, but
the callsite inside the JS_TO_WASM function was patched to call an
interpreter entry instead. We would not identify the call site as the
one to be patched during specialization, and would thus fail a DCHECK.
R=ahaas@chromium.org
BUG=v8:5822, chromium:702839
Change-Id: I148d98333051c399a4cb11bd9620b396f4eb261d
Reviewed-on: https://chromium-review.googlesource.com/456282
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43942}
We use LoadFromPrototype also for direct global loads. InitPrototypeChecks did not support this though, and would create a prototype chain check for objects beyond the direct global. This tries to ensure the property on the global itself doesn't exist, which is invalid.
Additionally this CL deletes duplicate code.
BUG=chromium:702798,v8:5561
Change-Id: I318a5b6cd5f7c3efdb3a003e34edd37d5d3f880b
Reviewed-on: https://chromium-review.googlesource.com/457369
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43935}
Don't ignore IfException (and IfSuccess) projections on JSForInNext
nodes during JSTypedLowering::ReduceJSForInNext, but instead rewrire
the IfException projection to the ForInFilter stub call, which can
throw exceptions in case of proxies.
R=yangguo@chromium.org
BUG=v8:6121
Review-Url: https://codereview.chromium.org/2761703002
Cr-Commit-Position: refs/heads/master@{#43925}
BUG=chromium:702793
Change-Id: Ia52823968a757f8f7fc8802deab60f570ffdb58c
Reviewed-on: https://chromium-review.googlesource.com/456280
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43920}
The fast-path for Array.prototype.indexOf first checks whether the
receiver is a fast-mode JSArray (and there are no elements in the
prototype chain in case of holey arrays), then loads the known
JSArray::length, and afterwards calls ToInteger on the fromIndex.
But this ToInteger(fromIndex) call can cause arbitrary side effects if
the fromIndex is a JSReceiver, in particular it can invalidate the
assumptions about the fast-mode of the receiver and the length. In the
worst case this leads to OOB memory access.
Quick-fix is to bailout to the runtime if the fromIndex is neither a Smi
nor undefined, which represents the common cases.
R=jarin@chromium.org
BUG=chromium:702058
Review-Url: https://codereview.chromium.org/2756663002
Cr-Commit-Position: refs/heads/master@{#43843}
Removes the --ignition-staging flag since it is no longer used
by anything and won't be a shipping configuration. Also removes
ignition_turbo variant from testrunner, since it is now
the same as the turbofan variant.
BUG=v8:4280
Change-Id: I3b96e986879fc70b8e202fe9496334828acdd0ba
Reviewed-on: https://chromium-review.googlesource.com/452621
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43806}
This fixes a corner-case in {KeyAccumulator::CollectOwnJSProxyKeys}
where the keys returned by {JSReceiver::OwnPropertyKeys} for an array
are not internalized and hence have a diverging identity from keys
returned by the "ownKeys" trap of a proxy.
R=cbruni@chromium.org
TEST=mjsunit/regress/regress-crbug-700678
BUG=chromium:700678
Change-Id: I5efd012eade14bd45c69e4abb0aeda684baf38f0
Reviewed-on: https://chromium-review.googlesource.com/452979
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43775}
The optimization
NumberFloor(NumberDivide(lhs, rhs))
to
NumberToInt32(NumberDivide(lhs, rhs))
for potentially negative lhs is not valid, since Math.floor rounds
towards -infinity, whereas ToInt32 truncates.
BUG=chromium:699282
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2743673002
Cr-Commit-Position: refs/heads/master@{#43699}
This fixes an incorrect usage of String::Flatten in EscapeRegExpSource.
It also adds %ConstructConsString (to easily and reliably construct cons
strings in tests) and Factory::NewConsString (to enable guaranteed cons
string construction without preemptive flattening attempts).
BUG=chromium:698790
Review-Url: https://codereview.chromium.org/2736383003
Cr-Commit-Position: refs/heads/master@{#43686}
The immediate passed to cmpw can be either a signed 16-bit or an
unsigned 16-bit integer, but the DCHECK was testing for signed 16-bit
values only.
R=mstarzinger@chromium.org
BUG=v8:6063
Review-Url: https://codereview.chromium.org/2735363002
Cr-Commit-Position: refs/heads/master@{#43671}
From asm.js code we might get an empty ArrayBuffer as heap memory. In
this case, both the old memory start and the new memory start will be
nullptr. The size however has to be patched from default_size to 0.
This CL changes code specialization to be able to either patch memory
references, or patch memory sizes or both.
R=titzer@chromium.org, ahaas@chromium.org
BUG=chromium:698587
Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146
Reviewed-on: https://chromium-review.googlesource.com/450257
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43613}
This involved adding a count_ member to SloppyBlockFunctionMap, so
to avoid making DeclarationScope larger, this patch makes the
creation of the map lazy, thus reducing the size of DeclarationScope
by several words in the process.
BUG=chromium:688567
Change-Id: If9a9eb2ccc01690fe10edadb3aa9625454ff4a19
Reviewed-on: https://chromium-review.googlesource.com/448701
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43558}
String::SlowFlatten assumed that ConsStrings with empty first parts have
flattened strings as their second part. TurboFan, however, can create
ConsStrings with empty first parts and arbitrary second parts. With
this CL we call String::Flatten on the second part of a ConsString if
the first part is empty, but only when String::Flatten would not call
String::SlowFlatten.
R=jkummerow@chromium.org
BUG=chromium:696651
Change-Id: I9acb681de1be695e1ec2f6f6d28b9e4dc4344e98
Reviewed-on: https://chromium-review.googlesource.com/448457
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43513}
The maybe-assigned flag of the catch variable was not preserved.
BUG=v8:5636,chromium:696332
Change-Id: I9c55e1b1312bdebc53bc45bc3ca1c982bdbe9846
Reviewed-on: https://chromium-review.googlesource.com/447680
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43506}
Previously, we over-approximated Scope::scope_calls_eval_ in
arrow functions: if either the outer scope or the arrow function
parameters had a direct eval call, we marked both scopes as calling
eval. This over-approximation kept getting us into trouble, though,
especially when eager or lazy parsing would disagree about the
"calls eval" bit.
This patch instead tracks eval calls accurately, using a boolean on
Scope::Snapshot that is reset as appropriately depending on whether
a particular AssignmentExpression turned out to be an arrow parameter
list or not.
BUG=chromium:691687
Change-Id: I527dc59b4d32a2797805ff26dc9f70b1311377b2
Reviewed-on: https://chromium-review.googlesource.com/446094
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43499}
The above intrinsic by now has to perform a check whether the prototype
of a derived constructor is actually a constructor function itself. This
is done as part of the {JSGetConstructorCall} operator. The intrinsic
should just reduce down to the operator to maintain correct semantics.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-696622
BUG=chromium:696622
Change-Id: Ia19c188f17ad16b12248db1f01a01b8d7258499b
Reviewed-on: https://chromium-review.googlesource.com/447716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43479}
When an instance of a constructor goes dictionary mode, this changes the initial map
of that constructor to also be in dictionary mode. This avoids spurious hidden class
creation, that also results in IC misses.
BUG=
Change-Id: I0e70f822ac345d0224f2092ec473621a603d4cc5
Reviewed-on: https://chromium-review.googlesource.com/446361
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43452}
This fixes a corner-case where the call reduction of the aforementioned
getter did not simulate the {ToObject} conversion of the receiver value
as required by the spec. This caused the wrong prototype to be constant
promoted (i.e. {null} instead of wrapper object prototype).
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-694709
BUG=chromium:694709
Change-Id: Idf3a37071949d9ddaf5ef43974570c06fd31c0c9
Reviewed-on: https://chromium-review.googlesource.com/445818
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43376}
This fixes a missing name check for keyed property loads targeting the
global object where the feedback was warmed up with a single name. This
affects {JSLoadProperty} nodes only, syntactic global property loads via
the {JSLoadGlobal} operator are not affected.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-694416
BUG=chromium:694416
Change-Id: I54aa3f27eaa72630539f02602ec7642b04835b27
Reviewed-on: https://chromium-review.googlesource.com/445224
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43344}
info.This returns a Local<Object>, which results in a call to
Utils::OpenHandle<JSReceiver>. Casting to a Local<Value> first uses the
correct OpenHandle<Object> overload.
BUG=chromium:693500
Review-Url: https://codereview.chromium.org/2706833002
Cr-Commit-Position: refs/heads/master@{#43314}
The bytecode generator did not necessarily know for which scope, and
thus language mode, it was generating code, because it only tracked
scopes that have a context. This led to wrong behavior in some
examples involving class expressions (which are always in strict
mode).
With this CL, the bytecode generator explicitly tracks the current
scope, independent of whether it has a context.
BUG=v8:5927
Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b
Reviewed-on: https://chromium-review.googlesource.com/444785
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43300}
Currently, typeof o, where o is an undetectable
callable object (such as document.all), returns 'function' if
optimised. It should, however, return 'undefined'.
This CL excludes undetectable objects from the optimization
resulting in type 'function' and renames the related code to
reflect that.
BUG=v8:5972
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2697063002
Cr-Commit-Position: refs/heads/master@{#43298}
One optimization in the machine-operator-reducer did not consider that
that word32 shift left instructions only consider the last 5 bits of
the shift input.
The issue only occurs for WebAssembly because in JavaScript we always
add a "& 0xf" on the shift value to the TurboFan graph.
For additional background: The JavaScript and WebAssembly spec both
say that only the last 5 bits of the shift value are used in the
word32-shift-left operation. This means that an "x << 0x29", in the
code is actually executed as "x << 0x09". Therefore the changes in
this CL are okay because they mask the last 5 bit of the shift value.
BUG=chromium:689450
Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
Reviewed-on: https://chromium-review.googlesource.com/439312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}
@@replace has a pretty complex implementation, taking different paths
for various situations (e.g.: global/nonglobal regexp, functional/string
replace argument, etc.). Each of these paths must implement similar
logic for calling into the RegExpBuiltinExec spec operation, and many
paths get this subtly wrong.
This CL fixes a couple of issues related to the way @@replace handles lastIndex:
* All paths now respect lastIndex when calling into exec (some used to assume 0).
* lastIndex is now advanced after a successful match for sticky regexps.
* lastIndex is now only reset to 0 on failure for sticky regexps.
BUG=v8:5361
Review-Url: https://codereview.chromium.org/2685183003
Cr-Commit-Position: refs/heads/master@{#43234}
The mips64 implementation always ended up in the slowpath due to some
loads that were the wrong width, so that is also fixed here.
BUG=v8:5974
Change-Id: Ie448a1fab5b7fca87597c5a1bf75443864e30c28
Reviewed-on: https://chromium-review.googlesource.com/443247
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43222}
ParserBase::is_any_identifier currently does not recognise
Token::ESCAPED_STRICT_RESERVED_WORD as an identifier. This seems different
from what ParserBase::ParseIdentifierName does, and also prevents
"l\u0065t", unlike "let", from becoming a label.
This CL extends is_any_identifier to also accept ESCAPED_STRICT_RESERVED_WORD.
BUG=v8:5692
Review-Url: https://codereview.chromium.org/2695973003
Cr-Commit-Position: refs/heads/master@{#43204}
This adds support for deoptimizing into the JSConstructStub after the
receiver instantiation but before the actual constructor invocation.
Such a deoptimization point is needed for cases where instantiation
might be observed (e.g. when new.target is a proxy) and hence might
trigger a deopt.
We use this new deoptimization point for the "after" frame-state the
inliner attaches to {JSCreate} nodes being inserted when constructor
calls are being inlined.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5638b
BUG=v8:5638
Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd
Reviewed-on: https://chromium-review.googlesource.com/440125
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43149}
We cannot skip the @@hasInstance lookup in instanceof depending on a
global protector cell, as the lookup of the property is observable
via proxies or accessors. So remove the global protector and properly
implement CSA::InstanceOf via GetPropertyStub, with an appropriate
fast-path for Function.prototype[@@hasInstance] where we call the
builtin code object directly if the function matches, skipping all
the checks from the call sequence, and also avoid the redundant
ToBoolean conversion on the result.
R=yangguo@chromium.orgTBR=ulan@chromium.org
BUG=v8:5958
Review-Url: https://codereview.chromium.org/2684033012
Cr-Commit-Position: refs/heads/master@{#43137}
This fixes the case where the index passed to {HMaybeGrowElements} used
to derive the new capacity for the elements backing store does not fit
into Smi range. Such an overflow would fail the capacity check and cause
growing to be skipped. Subsequent keyed stores would potentially go out
of bounds.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-686427
BUG=chromium:686427
Review-Url: https://codereview.chromium.org/2686263002
Cr-Commit-Position: refs/heads/master@{#43101}
