Confirmed stable and Canary on Windows, works for Edge/Gecko.

It's been almost two months. Any progress on this?
It is really important for us as we use eval in https://repl.it and we have millions of users affected by this across schools and universities around the world

Sorry about the delay on this bug. This looks to me to be closely related to v8:5295 . I am working on a fix at https://codereview.chromium.org/2435023002 but encountering some issues. As a workaround, you could consider wrapping the code inside the eval in an immediately invoked function expression.

Thanks for following up, Dan! Alas, we can't wrap in an IIFE because as users execute the code they expect to interact with it in the REPL (i.e. the global environment must have their variables).

I found another workaround, if I see a const in the code I can add a `'use strict';` and that should work. 

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

commit 53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1
Author: littledan <littledan@chromium.org>
Date: Tue Dec 20 16:23:19 2016

Use a different map to distinguish eval contexts

eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,

  eval('var x; let y; ()=>y')

introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.

This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.

BUG= v8:5295 ,  chromium:648719 

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

[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/ast/scopes.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/code-factory.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/code-factory.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/code-stubs.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/code-stubs.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/compiler/ast-graph-builder.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/compiler/bytecode-graph-builder.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/compiler/js-create-lowering.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/compiler/js-generic-lowering.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/compiler/js-operator.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/compiler/js-operator.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/contexts-inl.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/contexts.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/contexts.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/arm/lithium-codegen-arm.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/arm64/lithium-codegen-arm64.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/ia32/lithium-codegen-ia32.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/mips/lithium-codegen-mips.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/mips64/lithium-codegen-mips64.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/ppc/lithium-codegen-ppc.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/s390/lithium-codegen-s390.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/x64/lithium-codegen-x64.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/crankshaft/x87/lithium-codegen-x87.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/debug/debug-scopes.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/factory.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/factory.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/flag-definitions.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/arm/full-codegen-arm.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/arm64/full-codegen-arm64.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/ia32/full-codegen-ia32.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/mips/full-codegen-mips.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/mips64/full-codegen-mips64.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/ppc/full-codegen-ppc.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/s390/full-codegen-s390.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/x64/full-codegen-x64.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/full-codegen/x87/full-codegen-x87.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/heap/heap.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/heap/heap.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/interpreter/bytecode-array-builder.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/interpreter/bytecode-array-builder.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/interpreter/bytecode-generator.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/interpreter/bytecodes.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/interpreter/interpreter.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/objects-inl.h
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/runtime/runtime-scopes.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/src/runtime/runtime.h
[add] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/test/mjsunit/regress/regress-5295-2.js
[add] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/test/mjsunit/regress/regress-5295.js
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/test/mjsunit/regress/regress-5736.js
[add] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/test/mjsunit/regress/regress-648719.js
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/test/unittests/compiler/js-create-lowering-unittest.cc
[modify] https://crrev.com/53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1/test/unittests/interpreter/bytecode-array-builder-unittest.cc

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

commit cc48d2b1d87f4cab501a66eea2083f1c64d5007b
Author: bjaideep <bjaideep@ca.ibm.com>
Date: Tue Dec 20 19:12:21 2016

PPC: Use a different map to distinguish eval contexts

Port 53fdf9d1926c6a6f9a2d2acf0c303ae4c71210a1

Original Commit Message:

    eval() may introduce a scope which needs to be represented as a context at
    runtime, e.g.,

      eval('var x; let y; ()=>y')

    introduces a variable y which needs to have a context allocated for it. However,
    when traversing upwards to find the declaration context for a variable which leaks,
    as the declaration of x does above, this context has to be understood to not be
    a declaration context in sloppy mode.

    This patch makes that distinction by introducing a different map for eval-introduced
    contexts. A dynamic search for the appropriate context will continue past an eval
    context to find the appropriate context. Marking contexts as eval contexts rather
    than function contexts required updates in each compiler backend.

R=littledan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG= v8:5295 ,  chromium:648719 
LOG=N

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

[modify] https://crrev.com/cc48d2b1d87f4cab501a66eea2083f1c64d5007b/src/full-codegen/ppc/full-codegen-ppc.cc

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Given that this is not a regression in Chrome 56, I don't think have to merge this to Stable.

I agree; this was a long-standing bug (from back when sloppy-mode let was first enabled), and the fix will be difficult to backport. I don't think it needs to be backported to any prior Chrome version; a Node backport could be done if it is a big source of complaints, but keep in mind that it will be non-trivial (I have heard most complaints here from the web side).