ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6513732810440704

Adam, can you please have a look at this one? Seems to depend on with and arrow destructuring.

Minimized test case (flags: "--always-opt --no-lazy --turbo-filter=whatever"):

```
function g() { eval() }
with ({}) { }
f = ({x}) => { };
f();
```

The thing that causes the CHECK failure is that, upon recompilation, the variable x, which was marked as context-allocated on first compilation, is marked as local during recompilation. Still working on why this set of flags causes that to happen, and why it doesn't happen without those flags.

It seems that "--turbo-filter=whatever" does what I would have expected "--noturbo --noignition" to do.

Also, my hunch is that what causes this to work "correctly" in the ignition/turbo path is that our eager compilation of the arrow function, which treats x as context-allocated, never gets re-run. Instead we use the BytecodeGraphBuilder, which avoids being able to make the mistake of re-parsing f (and thus seeing, on a lazy parse, that x does not need to be context-allocated).

The right fix here is to be exact about recording the presence (or non-presence) of eval calls inside arrow parameter lists. I'm going to see about finally doing that.

Lowering priority because I think this configuration is unlikely to exist in the wild.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/fc023664bdb2bb9d76850655c1c8e7770802904e

commit fc023664bdb2bb9d76850655c1c8e7770802904e
Author: Adam Klein <adamk@chromium.org>
Date: Tue Feb 28 19:15:09 2017

Accurately record eval calls in arrow parameter lists

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}
[modify] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/src/ast/scopes.cc
[modify] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/src/ast/scopes.h
[modify] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/src/parsing/parse-info.cc
[modify] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/src/parsing/parse-info.h
[modify] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/src/parsing/parser-base.h
[modify] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/src/parsing/parser.cc
[add] https://crrev.com/fc023664bdb2bb9d76850655c1c8e7770802904e/test/mjsunit/regress/regress-crbug-691687.js