This patch handles C-style, as well as for-in/of loops. for-await loops
will be changed in a followup.

Bug: v8:6724
Change-Id: I264b8c2d41c0318e796839bf204f7d77b6d24dd8
Reviewed-on: https://chromium-review.googlesource.com/617410Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47404}

Move the desugaring into BytecodeGenerator per TODOs.

BUG=v8:6472
R=tebbi@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org

Change-Id: Ic482bee18d6e6fe73de4c5f9abaf4feda7be2dd5
Reviewed-on: https://chromium-review.googlesource.com/550396Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47403}

Have asm.js instantiate failures tail call the function object again, which
has been reset to the CompileLazy builtin, rather than explicitly calling
the CompileLazy runtime function. This ensures that we call any optimized
code or respect the optimization marker on the feedback vector, and can
introduce DCHECKS in Compiler::Compile to this effect.

Change-Id: I69a1de006c4da8f667a3e8ae8cf69ecf241dae9a
Reviewed-on: https://chromium-review.googlesource.com/618714
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47402}

Make it consistent so that registers in all architecture have a member
function called `bit()`.

Bug: 
Change-Id: Ie6323f81d4ecab1557259a43a30100d8da8b35f1
Reviewed-on: https://chromium-review.googlesource.com/618872
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47401}

glibc before 2.17 has a bug that makes it impossible to execute binaries
that have single-byte thread-local variables:

    % node --version
    node: error while loading shared libraries: cannot allocate memory
    in static TLS block

Work around that by making the one instance in the V8 code base an int.

See: https://sourceware.org/bugzilla/show_bug.cgi?id=14898
See: https://github.com/nodesource/distributions/issues/513
See: https://github.com/nodejs/build/pull/809
Change-Id: Iefd8009100cd93e26cf8dc5dc03f2d622b423385
Reviewed-on: https://chromium-review.googlesource.com/612351
Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47400}

This is a reland of 21da12a9
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
> 
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
> 
> Also does some other cleanup:
>  - Removes CompileUnoptimizedFunction and inlines into new Compiler function
>  - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
>    out of FinalizeUnoptimizedCompile.
> 
> BUG=v8:6409
> 
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}

TBR=yangguo@chromium.org
TBR=jarin@chromium.org

Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}

This CL introduces 6 tests that verify that the effects of a grow_memory
instruction executed inside a function are visible also from the caller of
the function.

The tests verify that:

 * the current_memory instruction returns the correct value after
 returning from a function that grew memory;

 * accessing a memory page that has been created inside a function does
 not trap in the caller;

 * when a function grows the memory and then store something in the grown
 memory, the caller always reads from the grown memory. This checks that
 the memory start address gets updated in the caller (the memory buffer
 could in fact be relocated by the grow_memory instruction).

These tests are implemented for direct and indirect function calls.

R=ahaas@chromium.org,clemensh@chromium.org

Change-Id: Iac8db0fa7a6dd6f530e090af5423fc165d87e863
Reviewed-on: https://chromium-review.googlesource.com/616150
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47398}

This reverts commit 21da12a9.

Reason for revert: Failing on arm64 simulator

Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
> 
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
> 
> Also does some other cleanup:
>  - Removes CompileUnoptimizedFunction and inlines into new Compiler function
>  - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
>    out of FinalizeUnoptimizedCompile.
> 
> BUG=v8:6409
> 
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org

Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}

Bug: 
Change-Id: I5b5477b55f42cdfa7978bbe6b8610302f0ec41fb
Reviewed-on: https://chromium-review.googlesource.com/612085Reviewed-by: Miran Karić <Miran.Karic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#47396}

The WASM spec maximum memory size is higher than internal V8 maximum object
size. When a memory object grows above this limit (and only in that case), we
should signal an error.

This worked for not-exported memory; however when growing exported memory, the
code was comparing the V8 memory limit with the maximum number of pages defined
in the module, instead of the current number of pages + the number of new
required pages. This lead to signaling errors even when growing exported memory
below the V8 limit if the maximum number of pages specified in the module was
higher than the V8 limit.

GrowMemoryBuffer already checks that we do not grow a memory buffer past the
maximum size specified as parameter, so we can pass it the minimum between the
the V8 limit and the maximum number of pages specified in the module.

This CL introduces a test in test/mjsunit/wasm/import-memory.js that triggers
the problematic path and a patch to fix it.

R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org

Change-Id: I5a8da420418b394d61e1ba3cdf4408c3c09e61b6
Reviewed-on: https://chromium-review.googlesource.com/600217Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47395}

Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.

Also does some other cleanup:
 - Removes CompileUnoptimizedFunction and inlines into new Compiler function
 - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
   out of FinalizeUnoptimizedCompile.

BUG=v8:6409

Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}

'9. Let targetName be ? Get(Target, "name").' didn't produce required
side effects.

Bug: v8:6712
Change-Id: Iebf007b4e93ebbf9c6c85c9729d972a8c1a7b129
Reviewed-on: https://chromium-review.googlesource.com/616727Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47393}

R=cbruni@chromium.org

Bug: v8:6726
Change-Id: If56ce1a0b00b98ede2bb101cb9697ec516d19e81
Reviewed-on: https://chromium-review.googlesource.com/616641Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47392}

This CL solves recent clang compilation error:
"src/wasm/function-body-decoder.cc:1418:18: error: comparison of two
values with different enumeration types in switch statement
('v8::internal::wasm::ControlKind' and 'ControlKind')"

Bug: 
Change-Id: I6cb32bb3d42256a80d6f9222f5450ee93ce1021a
Reviewed-on: https://chromium-review.googlesource.com/615247Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47391}

Here the token cannot be Token::INIT since it's coming from the Scanner. Scanner
never returns Token::INIT, and Token::INIT is only used internally in the AST.

Bug: 
Change-Id: I185e6d3330651b7ee784b916908e7d8d803b63b9
Reviewed-on: https://chromium-review.googlesource.com/616282
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47390}

In graph building, use liveness information to only create Phis
for live registers when merging two environments, or when preparing
a loop header. Similarly, only create loop exit value nodes for
live registers when exiting a loop.

Bug: v8:6701
Change-Id: Id6ac6a5518e6f1762530d871e92a46f42397928b
Reviewed-on: https://chromium-review.googlesource.com/615173
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47389}

The accumulator should never be alive when jumping back to a loop
header, or jumping out of a loop. This means that as far as far as
TurboFan is concerned, we never need to create Phis or LoopExitValues
for the accumulator, as its value should not escape the loop.

For safety, this also augments the IsLivenessValid DCHECK in the
liveness analysis to check that the accumulator is not live in these
cases, and amends the bytecode analysis tests to kill the accumulator
where necessary to ensure this.

As a drive-by, added some comments to the more complex bytecode analysis
tests, since figuring out what they were for and how to fix them took a
non-trivial amount of time.

Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef
Reviewed-on: https://chromium-review.googlesource.com/615168
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47388}

R=rmcilroy@chromium.org

Bug: v8:6409
Change-Id: I8205ca3e9587f4cb1d35d7edc1aa320814020ac4
Reviewed-on: https://chromium-review.googlesource.com/616665Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47387}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/179cd37..bee933a

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/b153f21..cd8447f

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/5bad4f2..874d630

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

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

I32x4 Neg, Eq/Ne/GtS/GeS/GtU/GeU
Reconstruct ro/RRO macro instructions with AVX_OP3_WITH_TYPE

Bug: 
Change-Id: I3e391f489717db3456b884c6df0b1756497a1846
Reviewed-on: https://chromium-review.googlesource.com/616463Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jing Bao <jing.bao@intel.com>
Cr-Commit-Position: refs/heads/master@{#47385}

Bug: v8:5855
Change-Id: Ie783318b2297f85a9f102e1266dfc1fac406435a
Reviewed-on: https://chromium-review.googlesource.com/466107
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47384}

This reverts commit a50b6751.

Reason for revert: Regression

Original change's description:
> [runtime] Port TypedArraySetFormArrayLike to C++
> 
> Bug: v8:6704
> Change-Id: I316f085801f4fb6a792124f9a6f80a16e6d43162
> Reviewed-on: https://chromium-review.googlesource.com/616721
> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47369}

TBR=franzih@chromium.org,bmeurer@chromium.org

Change-Id: Ibafeae41c85b6d7848b26dac7468057e1cea4769
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6704
Reviewed-on: https://chromium-review.googlesource.com/617480Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47383}

This patch simplifies and reduces code duplication & dead branches
in PatternRewriter, especially relating to handling of destructuring
assignments. It also adds additional DCHECKs to capture invariants.

It should have no change in behavior.

Change-Id: I02bc6c30a1cae8a60c4c5e9033b90953d136212e
Reviewed-on: https://chromium-review.googlesource.com/612511
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47382}

R=mlippautz@chromium.org

Bug: 
Change-Id: I0df355cdfcf77a1462948b82479f2626d94ca5cc
Reviewed-on: https://chromium-review.googlesource.com/614623Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#47381}

This saves one pointer in Assignment for non-compound
assignment expressions.

Change-Id: I7ec32c1d378917c81ab55c42733b6af450ce65db
Reviewed-on: https://chromium-review.googlesource.com/612673
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47380}

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

This patch ensures that all code path of the external memory pressure
handler pass the kGCCallbackFlagCollectAllExternalMemory flag to the
embedder. This is necessary to force Oilpan GC.

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

This is a very minor cleanup noticed when reading this code. It's simply
a slight reduction in Parser/AST size.

Change-Id: Ice81253d1624723ef124a19442b0dcf4b77f4345
Reviewed-on: https://chromium-review.googlesource.com/614585Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47377}

This removes brittle Scope walking in FinalizeForOfStatement()
by making ParserBase call InitializeForEachStatement() while
in the proper Scope.

Bug: v8:6724
Change-Id: I6e828ccb3a5e4d98633a95a2bfb8d255ad0fc0eb
Reviewed-on: https://chromium-review.googlesource.com/614654Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47376}

This loop doesn't itself have a source position, so I wouldn't think
block coverage of it would make any sense (and all tests continue
to pass).

Removing this argument will make some refactoring I'm working on easier.

Bug: v8:6724
Change-Id: I4d6b734e077d9e61ad9362d07e57f155ec556221
Reviewed-on: https://chromium-review.googlesource.com/615385Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47375}

NOTRY=true
TBR=yangguo@chromium.org

Bug: chromium:726584
Change-Id: Ie094a57105ad5c5098b0b133c9ca3661576f09a8
Reviewed-on: https://chromium-review.googlesource.com/616682
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47374}

R=alph@chromium.org

Bug: 
Change-Id: Ie9088cd189fcf3af08b06f3021ff4ff1641b7791
Reviewed-on: https://chromium-review.googlesource.com/601928
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47373}

Bug: v8:6664, v8:6557
Change-Id: Ib2180e38c8b07cda102ccb160dfd44197d828be0
Reviewed-on: https://chromium-review.googlesource.com/602229
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47372}

FPRegister <-> FPRegister moves and swaps were implemented using the FMOV
instruction, whatever the size of the register. However, FMOV only supports
Float and Double moves, it cannot move a whole 128bit register.

Instead, use the vector MOV instruction:

- Simd128 move:      mov vd.16b, vn.16b
- Float/Double move: mov vd.8b, vn.8b

Bug: 
Change-Id: Ie793078baf3fb816e4047062285bbdaf35483949
Reviewed-on: https://chromium-review.googlesource.com/591308Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#47371}

The code generator uses `ip` as a scratch register directly to assemble a
"Constant -> Float stack slot" move. However, the assembler may also use it to
compute the address.

If we try to assemble such a move and the stack slot is out of range of a store
we get the following:
~~~
movw ip, #52429
movt ip, #15820
movw ip, #59328   ; Use ip to compute the address!
movt ip, #65535
str ip, [fp, +ip]
~~~

Bug: 
Change-Id: I97a7b606e3f1d53ed44cc7787e49109cf7a7ab16
Reviewed-on: https://chromium-review.googlesource.com/602230Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#47370}

Bug: v8:6704
Change-Id: I316f085801f4fb6a792124f9a6f80a16e6d43162
Reviewed-on: https://chromium-review.googlesource.com/616721
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47369}

R=petermarshall@chromium.org

Bug: chromium:617892
Change-Id: I4077ae567297d18edd6c6748f9f64bbdafb34896
Reviewed-on: https://chromium-review.googlesource.com/616561
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47368}

Now that OSR is done during graph building, we no longer have to
special-case OSR loops in the loop assignment analysis, as we no longer
have the restriction that registers are 'assigned' an OSRValue inside
the loop.

Bug: v8:6518
Change-Id: Ib4fa139091d77efa16246ddc6e63a10cbb877ee4
Reviewed-on: https://chromium-review.googlesource.com/615167Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47367}

Makes ClusterFuzz start fuzzing with the flag on.

BUG=v8:5516

Change-Id: Ia80f7d22f12fe25efb226102a896e8b0e3537947
Reviewed-on: https://chromium-review.googlesource.com/610000
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47366}

Allowing GetModuleNamespace on a not-yet-evaluated module does not make a
lot of sense because accessing the namespace object before evaluation
can lead to surprising behavior.

R=adamk@chromium.org

Bug: v8:1569
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3e3feb344f6399bf92b3dabc97c571a61b38bd41
Reviewed-on: https://chromium-review.googlesource.com/613268Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47365}