Почему отладчик Chrome считает закрытую локальную переменную неопределенной?

Question

С помощью этого кода:

function baz() { 
    var x = "foo"; 

    function bar() { 
    debugger; 
    }; 
    bar(); 
} 
baz(); 

я получаю этот неожиданный результат:

Когда я изменить код:

function baz() { 
    var x = "foo"; 

    function bar() { 
    x; 
    debugger; 
    }; 
    bar(); 
} 

я получить ожидаемый результат:

Кроме того, если во внутренней функции есть вызов eval, я могу получить доступ к моей переменной, как я хочу сделать (не имеет значения, что я перехожу на eval).

Между тем, инструменты Firefox dev дают ожидаемое поведение в обоих обстоятельствах.

Что случилось с Chrome, что отладчик ведет себя менее удобно, чем Firefox? Я наблюдал это поведение некоторое время, вплоть до версии 41.0.2272.43 beta (64-разрядная версия).

Является ли это тем, что механизм javascript Chrome «сглаживает» функции, когда это возможно?

Интересно, если добавить вторую переменную, которую имеет значение, указанную во внутренней функции, переменная x по-прежнему не определена.

Я понимаю, что при использовании интерактивного отладчика часто возникают причуды с областью видимости и переменной определения, но мне кажется, что на основе спецификации языка должно быть «лучшее» решение этих причуд. Поэтому мне очень любопытно, что это связано с тем, что Chrome оптимизирован дальше Firefox. А также можно ли легко отключить эту оптимизацию во время разработки (возможно, они должны быть отключены, когда инструменты разработчика открыты?).

Кроме того, я могу воспроизвести это с точками останова, а также с заявлением debugger.

Answer 1

Я нашел v8 issue report который является точным о том, о чем вы просите.

Теперь, чтобы суммировать то, что сказано в этом отчете о проблеме ... v8 может хранить переменные, которые являются локальными для функции в стеке или в объекте «context», который живет в куче. Он будет выделять локальные переменные в стеке, пока функция не содержит никакой внутренней функции, которая относится к ним. Это оптимизация. Если любая функция относится к локальной переменной, эта переменная будет помещена в объект контекста (т. Е. В куче, а не в стеке). Случай eval является особенным: если он вообще вызван внутренней функцией, то в объект контекста помещаются все.

Причина для объекта контекста заключается в том, что в общем случае вы можете вернуть внутреннюю функцию из внешней, а затем стек, который существовал во время выполнения внешней функции, больше не будет доступен. Таким образом, все, что получает доступ к внутренней функции, должно пережить внешнюю функцию и жить в куче, а не в стеке.

Отладчик не может проверить те переменные, которые находятся в стеке. Что касается возникшую проблему при отладке, один участник проекта says:

Единственное решение, которое я мог думать о том, что всякий раз, когда DevTools это, мы бы deopt весь код и перекомпилировать с принудительным распределением контекста. Тем не менее, это привело бы к резкому повышению производительности при помощи devtools.

Вот пример «если какая-либо внутренняя функция относится к переменной, поместите ее в объект контекста». Если вы запустите это, вы сможете получить доступ к x в заявлении debugger, хотя x используется только в функции foo, , которая никогда не называется!

function baz() { 
    var x = "x value"; 
    var z = "z value"; 

    function foo() { 
    console.log(x); 
    } 

    function bar() { 
    debugger; 
    }; 

    bar(); 
} 
baz(); 

Answer 2

Я подозреваю, что это связано с перестановкой переменных и функций. JavaScript приносит все объявления переменных и функций в начало функции, в которой они определены. Дополнительная информация: http://jamesallardice.com/explaining-function-and-variable-hoisting-in-javascript/

Я уверен, что Chrome вызывает точку останова с переменной, недоступной для области видимости, поскольку в ней нет ничего другого. функция. Это похоже на работу:

function baz() { 
 
    var x = "foo"; 
 

 
    function bar() { 
 
    console.log(x); 
 
    debugger; 
 
    }; 
 
    bar(); 
 
}

Как это делает:

function baz() { 
 
    var x = "foo"; 
 

 
    function bar() { 
 
    debugger; 
 
    console.log(x);  
 
    }; 
 
    bar(); 
 
}

Надеется, что это, и/или ссылка выше помогает. Это мой любимый вид вопросов SO, BTW :)

Answer 3

Я также заметил это в nodejs.Я считаю (и я признаю, что это только предположение), что при компиляции кода, если x не отображается внутри bar, он не делает x доступным в пределах bar. Это, вероятно, делает его несколько более эффективным; проблема в том, что кто-то забыл (или не заботился), что даже если нет x в bar, вы можете решить запустить отладчик и, следовательно, по-прежнему необходимо получить доступ к x изнутри bar.

Answer 4

Вау, действительно интересно!

Как уже упоминалось, это похоже на scope, но более конкретно, относящийся к debugger scope. Когда внедренный скрипт оценивается в инструментах разработчика, он, как представляется, определяет ScopeChain, что приводит к некоторой причудливости (поскольку оно связано с областью инспектора/отладчика). Разновидность того, что вы писали это:

(EDIT - на самом деле, вы упоминаете это в оригинальном вопросе, Yikes, мой плохой!)

function foo() { 
    var x = "bat"; 
    var y = "man"; 

    function bar() { 
    console.log(x); // logs "bat" 

    debugger; // Attempting to access "y" throws the following 
       // Uncaught ReferenceError: y is not defined 
       // However, x is available in the scopeChain. Weird! 
    } 
    bar(); 
} 
foo(); 

Для амбициозных и/или любопытных, рамок (хе) из источника, чтобы увидеть, что происходит:

https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/inspector https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/debugger

Answer 5

Как @Louis сказал, что это вызвано оптимизациями v8. Вы можете пройти Call Stack к кадру, где эта переменная видна:

Или заменить debugger с

eval('debugger'); 

eval будет deopt текущий кусок