This changes most callers of ParseScopedStatement to call a new, simpler form
of ParseStatement, which takes only |labels| and |ok|. This allows us to remove
the |legacy| attribute from ParseScopedStatement.

The only remaining caller of ParseScopedStatement is ParseIfStatement.

This patch is a strict refactoring, and should change no behavior.

R=littledan@chromium.org

Review-Url: https://codereview.chromium.org/2699793002
Cr-Commit-Position: refs/heads/master@{#43259}

ES2017 forbids the sequence of tokens "let [" in in expression statements [1].

This CL makes ParserBase report those instances as SyntaxError. It also adds a
customised error message for that, because the standard "Unexpected token" is
not applicable: "let" itself is not forbidden in those context, only the
sequence of "let [".

[1] https://tc39.github.io/ecma262/#sec-expression-statement

BUG=v8:5686

Review-Url: https://codereview.chromium.org/2694003002
Cr-Commit-Position: refs/heads/master@{#43258}

This adds the possibility to specify a python script for post-processing stdout.

This also adds some system tests for testing the new feature.

NOTRY=true

Change-Id: I0383afb3e23513629508feeb639ed2dfce56b54a
Reviewed-on: https://chromium-review.googlesource.com/443449Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43257}

This improves the filter deciding whether a checkpoint needs to be
created. We now keep track of whether a node having an observable
side-effect has been created, allowing to elide checkpoint that are
provably effect-dominated by another checkpoint already.

By now the initial graphs contain an increasing amount of nodes marked
with {Operator::kNoWrite}, making this optimization worthwhile.

R=jarin@chromium.org

Change-Id: Ie7ffb67e1ab081ef7aa3017675afbe5f9e7601ab
Reviewed-on: https://chromium-review.googlesource.com/443466Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43256}

This upgrades to a precompiled plugin version including:
https://chromium.googlesource.com/v8/v8/+/4b0edcf7

BUG=v8:5970
TBR=clemensh@chromium.org,mstarzinger@chromium.org

Change-Id: I28ecdd568e4bc075533b3d14b7946a4a7ce5f9e0
Reviewed-on: https://chromium-review.googlesource.com/443648
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43255}

Errors are swallowed by promises, so just exit with stack trace.

Review-Url: https://codereview.chromium.org/2693383004
Cr-Commit-Position: refs/heads/master@{#43254}

The default locale can be changed in some environments with environment
variables. These environment variables used to allow the system to get
into an invalid state, where the default locale was unsupported. This
patch detects that case and falls back to "und" as the default locale
if there is an Intl service which does not support the locale that ICU
reports as the default. It also has a slight cleanup of surrounding code.

I haven't gone through the work to set up an automated test, as triggering
the case requires setting environment variables, which our tests don't tend
to do, but I tested interactively as follows:

dehrenberg@dehrenberg:~/v8/v8$ LC_ALL="tlh-FR" rlwrap out/Release/d8
V8 version 5.7.0 (candidate)
d8> new Intl.NumberFormat("foo").resolvedOptions().locale
"und"
d8> new Intl.NumberFormat().resolvedOptions().locale
"und"
d8>

dehrenberg@dehrenberg:~/v8/v8$ LC_ALL="de" rlwrap out/Release/d8
V8 version 5.7.0 (candidate)
d8> new Intl.NumberFormat().resolvedOptions().locale
"de"
d8> new Intl.NumberFormat("foo").resolvedOptions().locale
"de"
d8>

BUG=v8:4216

Review-Url: https://codereview.chromium.org/2646593002
Cr-Commit-Position: refs/heads/master@{#43253}

This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.

Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.

BUG=v8:5946
R=leszeks@chromium.org

Review-Url: https://codereview.chromium.org/2684033007
Cr-Original-Commit-Position: refs/heads/master@{#43240}
Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d
Review-Url: https://codereview.chromium.org/2684033007
Cr-Commit-Position: refs/heads/master@{#43252}

Enforce the invariant that unreachable implicates an empty live set and
fix the implementation of |= and &= operator.
This is a fix-up for http://crrev.com/2694103005.

R=vegorov@chromium.org
CC=mstarzinger@chromium.org, machenbach@chromium.org
BUG=v8:5970

Review-Url: https://codereview.chromium.org/2691103008
Cr-Commit-Position: refs/heads/master@{#43251}

We were looking at the unreachable flag or stack_depth of the target frame
instead of the current one in a couple of places (most notably BreakTo).
This change fixes these bugs and makes us pass the latest spec tests for
br_table validation. Also need to ensure that br_table targets have consistent
types, which is not implied if the stack is polymorphic.

R=titzer@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2696813002
Cr-Commit-Position: refs/heads/master@{#43250}

The serializer won't ever write a more complex object. Not validating this
allows other things to be used as keys, and converted to string when the
property set actually occurs. It turns out this gives an opportunity to trigger
OOM by giving an object a key which is a very large sparse array (whose string
representation is very large).

This case is now rejected by the deserializer.

BUG=chromium:686511

Review-Url: https://codereview.chromium.org/2697023002
Cr-Commit-Position: refs/heads/master@{#43249}

The SpeculativeNumberOp helper lives now in js-type-hint-lowering.cc and
is no longer needed in js-typed-lowering.cc.

R=mstarzinger@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2701643002
Cr-Commit-Position: refs/heads/master@{#43248}

BUG=v8:5974

Change-Id: If79ff5c29bea79ebf8019c4a8e72d2bd7c6b9029
Reviewed-on: https://chromium-review.googlesource.com/443448
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43247}

BUG=v8:5880
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng

Review-Url: https://codereview.chromium.org/2689283008
Cr-Commit-Position: refs/heads/master@{#43246}

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/439312Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}

Map OOM breaks generated by inspector to DebugEvent.OOM.
This avoids generating unintentional DebugEvent.Break events.

Also be more future-proof in event categorization.

On a related note, this CL also fixes a DCHECK in
Runtime::GetFrameDetails.

The receiver needs to be grabbed from the inlined frame, not
the outer optimized frame. Optimized frames only provide the
receiver on a best-effort basis.

BUG=v8:5950

Review-Url: https://codereview.chromium.org/2696173002
Cr-Commit-Position: refs/heads/master@{#43244}

R=eholk@chromium.org

Change-Id: Ieb88f807275e1cc31cc7715270e316c427b212d4
Reviewed-on: https://chromium-review.googlesource.com/442425
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43243}

Revert of Allow a ParseInfo without a script for %SetCode users (patchset #5 id:220001 of https://codereview.chromium.org/2684033007/ )

Reason for revert:
Please remove the file in status file too. Breaks presubmit:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/14754

Or lets call it post-submit :(

Original issue's description:
> This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.
>
> Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.
>
> BUG=v8:5946
> R=leszeks@chromium.org
>
> Review-Url: https://codereview.chromium.org/2684033007
> Cr-Commit-Position: refs/heads/master@{#43240}
> Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d

TBR=leszeks@chromium.org,mstarzinger@chromium.org,marja@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5946

Review-Url: https://codereview.chromium.org/2703553002
Cr-Commit-Position: refs/heads/master@{#43242}

Produce the same scopes / variables for parameters (part 3).

This CL fixes the ordering + variable types in PreParser when there are
simple parameters + a rest parameter. In that case, Parser declares
unnamed temporaries for the non-rest params, then the rest param, then
the named variables (which are not parameters) for the non-rest params.

BUG=v8:5516
R=vogelheim@chromium.org

Change-Id: I9b006595039c8002b0508d1d2a200aa9a0f3eae0
Reviewed-on: https://chromium-review.googlesource.com/443527Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43241}

This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.

Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.

BUG=v8:5946
R=leszeks@chromium.org

Review-Url: https://codereview.chromium.org/2684033007
Cr-Commit-Position: refs/heads/master@{#43240}

ES2016 changed the default timezone of dates to be conditional on
whether a time is included. The semantics were a compromise approach
based on web compatibility feedback from V8, but until now, we have been
shipping ES5.1 default timezone semantics. This patch implements the
new semantics, following ChakraCore and SpiderMonkey (though JSC
implements V8's previous semantics).

BUG=chromium:589858

Review-Url: https://codereview.chromium.org/2648603002
Cr-Commit-Position: refs/heads/master@{#43239}

Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ )

BUG=

Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6
Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43238}

This is in order to prevent accidental bugs in desugarings.

R=adamk@chromium.org
BUG=v8:5636

Review-Url: https://codereview.chromium.org/2693313002
Cr-Commit-Position: refs/heads/master@{#43237}

BUG=chromium:690003

Change-Id: I0f80911426e9b201be61af313b4b5cacbb357bb5
Reviewed-on: https://chromium-review.googlesource.com/443329Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43236}

This handles arithmetic addition operations during the early type-hint
lowering (i.e. during graph construction). The string addition case is
still handled by {JSTypedLowering} as it needs static type information.

R=bmeurer@chromium.org

Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8
Reviewed-on: https://chromium-review.googlesource.com/443185Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43235}

@@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 parser was finalizing the inner block scope, but not clearing the
inner block's scope pointer. This doesn't (yet) have any behavioral
difference, but makes it easier to make assumptions about the structure
of the AST vs the scope chain.

R=neis@chromium.org

Review-Url: https://codereview.chromium.org/2696233003
Cr-Commit-Position: refs/heads/master@{#43233}

This was omitted in:
https://codereview.chromium.org/2615623003

TBR=clemensh@chromium.org,mtrofin@chromium.org
NOTRY=true

Change-Id: I78449fe72e27976b95a9557e0bd8f986ed8caa64
Reviewed-on: https://chromium-review.googlesource.com/443526Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43232}

The inspector uses V8's API handles and should not access
V8 internals. This change makes sure it can use the coverage
data in an encapsulated way.

R=jgruber@chromium.org, kozyatinskiy@chromium.org
BUG=v8:5808

Review-Url: https://codereview.chromium.org/2696163002
Cr-Commit-Position: refs/heads/master@{#43231}

- Clear flags to avoid the quite expensive query for whether this page
  is to be swept.
- Use a vector instead of a list as we always expect a small number of
  pages to go through the pool and we want to avoid memory management on
  this path.

BUG=

Change-Id: If3c0ad480b8e4f3ccf5a0ef43200c5269822245d
Reviewed-on: https://chromium-review.googlesource.com/443248
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43230}

This wraps float arrays with a proxy to make raw buffer use slow paths avoiding different NAN patterns.

This also mocks out large typed arrays when passing the lenth as third constructor parameter.

BUG=chromium:691287,chromium:690898
NOTRY=true

Change-Id: Ic4295b0d8690e5209aceeda9ed93efdd580194c0
Reviewed-on: https://chromium-review.googlesource.com/441624
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43229}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/5af1827..c8fd116

Rolling v8/test/wasm-js: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/680fa9a..b96d096

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/7336c94..574285d

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: Ib309b71a427e5e53b75ec3c803f63c699936bbbb
Reviewed-on: https://chromium-review.googlesource.com/443665Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43228}

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2697713006
Cr-Commit-Position: refs/heads/master@{#43227}

R=gsathya@chromium.org

Review-Url: https://codereview.chromium.org/2693063005
Cr-Commit-Position: refs/heads/master@{#43226}

Some of these functions are invoked by BytecodeGenerator due to parser
desugarings, and moving the context indices cause
BytecodeExpectationsPrinter to render them as something
useful/meaningful.

BUG=
R=jgruber@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/2695323002
Cr-Commit-Position: refs/heads/master@{#43225}

When --harmony-async-iteration is enabled, it is now possible to
use the for-await-of loop, which uses the Async Iteration protocol
rather than the ordinary ES6 Iteration protocol.

the Async-from-Sync Iterator object is not implemented in this CL,
and so for-await-of loops will abort execution if the iterated object
does not have a Symbol.asyncIterator() method. Async-from-Sync
Iterators are implemented seperately in https://codereview.chromium.org/2645313003/

BUG=v8:5855, v8:4483
R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/2637403008
Cr-Commit-Position: refs/heads/master@{#43224}

BUG=

Change-Id: I7215f298d7da4f5104449cc9198588801642bba1
Reviewed-on: https://chromium-review.googlesource.com/443126Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43223}

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}

These experimental natives previously only installed functions to the
appropriate parent. In this patch, the exports container is retained
so that the bootstrapper may install the functions instead. This
change is intended to reduce startup time. SharedArrayBuffer retains
some experimental natives exported from JS; this may be addressed
in a follow-on patch. The patch includes some minor cleanup of the
bootstrap process by removing "experimental exports", which was unused.

R=yangguo@chromium.org
BUG=v8:5880
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng

Review-Url: https://codereview.chromium.org/2683083003
Cr-Commit-Position: refs/heads/master@{#43221}

- Different places used is_simple to mean different things; renamed one.

- No need to do Scope::SetHasNoSimpleParameters multiple times.

- Normally we create VAR parameters with a name, or (for destructuring
  parameters), TEMPORARY parmeters with an empty name. *Except* for
  destructuring rest parameters; then we create VAR a parameter with an empty
  name. This CL makes the empty-named parameter TEMPORARY instead of VAR.

- This makes it clear that Parser::DeclareFormalParameters declares exactly
  those params which Parser::BuildParamerterInitializationBlock doesn't declare.

- This unification doesn't change any functionality, but it makes sense to do
  since I'll need to make PreParser emulate what Parser does; this way I don't
  need to emulate the weird behavior.

BUG=v8:5501

Change-Id: Ifa6c116bc5908f4e03a36e74f47558888d1582bd
Reviewed-on: https://chromium-review.googlesource.com/443106Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43220}