Able to reproduce the issue using latest Chrome version 58.0.3029.96 on Mac 10.12.4, Win 10 and Ubuntu 14.04

Below is the bisect information:

Unable to invoke the builds using hasbisect-per-revision. Hence providing the Chromium bisect.

Good build: 49.0.2613.0 (Revision: 367537)
Bad build:  49.0.2615.0 (Revision: 367975)

You are probably looking for a change made after 367789 (known good), but no later than 367791 (first known bad)..

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/b7c3414768afff35204a6c6b869c47d90d3953e0..738ab011f3ba03a698ba51e8a525b41a3605e33d

@v8-autoroll: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review URL: https://codereview.chromium.org/1569433002

Thank You.

Correction
==========

Below is the possible suspect

CHANGELOG URL:
https://chromium.googlesource.com/v8/v8/+log/5041f175..aca25b0c

@jkummerow: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review URL: https://codereview.chromium.org/1559323002

Thank you.

Can you please bisect into the V8 roll to figure out which V8 commit broke it?

Unfortunately the script do not support bisecting within the V8 roll.Can we target to have a fix during M60 time frame?

From a glance at the test case and the changelog, I think this is almost certainly https://chromium.googlesource.com/v8/v8/+/fcff8588a5a01587643d6c2507c7b882c78a2957 (ES2015 sloppy block function hoisting).

Given how old this bug is (present since M49), I don't see the urgency to get this into M60.

littledan, do you mind taking a look?

Thanks for reporting this issue. This seems like something we should fix--although eval isn't exactly the same as no-eval, I agree with your spec reading here. Also, V8 seems to be the only engine with this bug, as eshost shows:

littledan@littledan-ThinkPad-T460p:~$ eshost -e "eval('with ({a: 1}) { function a() {} }; a')"
#### chakracore
function a() {}

#### jsc
function a() {}

#### spidermonkey
function a() {}

#### d8
function a() {}

littledan@littledan-ThinkPad-T460p:~$ eshost -e "(function() { return eval('with ({a: 1}) { function a() {} }; a') })()"
#### chakracore
function a() {}

#### jsc
function a() {}

#### spidermonkey
function a() {}

#### d8
undefined

It looks like this behavior is a pretty fundamental result of the way sloppy-mode block-scoped function hoisting is implemented. If the sloppy-mode block-scoped function declaration is at the top level of the eval, rather than within a function, it is scope-analyzed as DYNAMIC_GLOBAL. (If it were within a function, then it could be statically resolved.)

I don't see a particular way that we can reference a half-analyzed variable at runtime--it ultimately needs to be either a local, dynamic local, or dynamic global. I think fixing this will require adding something different--I can't see any other cases where this comes up, so it seems like we need some sort of lookup type that's like DYNAMIC_GLOBAL but skips with-scopes, just for this particular case. If anyone has any other ideas, I'd be interested to hear it; otherwise, I'll work on an implementation of this lookup type.

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

commit d54ffadfdaa570600b6e4d5fb1aa128a4b629135
Author: Daniel Ehrenberg <littledan@chromium.org>
Date: Thu Jun 22 08:18:55 2017

[scopes] Fix sloppy-mode block-scoped function hoisting edge case

In edge cases such as the following, sloppy-mode block-scoped function
hoisting is expected to occur:

  eval(`
    with({a: 1}) {
      function a() {}
    }
  `)

In this case, there should be the equivalent of a var declaration
outside of the eval, which gets set to the value of the local function
a when the body of the with is executed.

Previously, the way that var declarations are hoisted out of eval
meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
assignment. However, such a lookup mode meant that the object in the
with scope received the assignment!

This patch fixes that error by marking the assignments produced by
the sloppy mode block scoped function hoisting desugaring so as to
generate a different runtime call which skips with scopes.

Bug:  chromium:720247 ,  v8:5135 
Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
Reviewed-on: https://chromium-review.googlesource.com/529230
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46116}
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/ast/ast.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/ast/scopes.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/compiler/bytecode-graph-builder.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/compiler/bytecode-graph-builder.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/contexts.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/globals.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecode-array-builder.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecode-array-builder.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecode-flags.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecode-flags.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecode-generator.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecode-generator.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/bytecodes.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/interpreter/interpreter-generator.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/runtime/runtime-scopes.cc
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/src/runtime/runtime.h
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/cctest/interpreter/bytecode_expectations/CallLookupSlot.golden
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/cctest/interpreter/bytecode_expectations/LookupSlot.golden
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/cctest/interpreter/bytecode_expectations/LookupSlotInEval.golden
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/cctest/interpreter/bytecode_expectations/LookupSlotWideInEval.golden
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/mjsunit/es6/block-sloppy-function.js
[add] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/mjsunit/regress/regress-720247.js
[modify] https://crrev.com/d54ffadfdaa570600b6e4d5fb1aa128a4b629135/test/unittests/interpreter/bytecode-array-builder-unittest.cc

Marking as fixed per #c11