Perché il debugger di Chrome ritiene che la variabile locale chiusa non sia definita?

Con questo codice:

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

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

Ottengo questo risultato inaspettato:

Quando cambio il codice:

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

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

Ottengo il risultato atteso:

Inoltre, se c'è qualche chiamata evalall'interno della funzione interna, posso accedere alla mia variabile come voglio fare (non importa a cosa passo eval).

Nel frattempo, gli strumenti di sviluppo di Firefox forniscono il comportamento previsto in entrambe le circostanze.

Che succede con Chrome che il debugger si comporta in modo meno conveniente di Firefox? Ho osservato questo comportamento per qualche tempo, fino alla versione 41.0.2272.43 beta inclusa (64 bit).

Il motore javascript di Chrome "appiattisce" le funzioni quando può?

È interessante notare che se aggiungo una seconda variabile a cui fa riferimento la funzione interna, la xvariabile è ancora indefinita.

Capisco che ci sono spesso stranezze con ambito e definizione variabile quando si utilizza un debugger interattivo, ma mi sembra che in base alle specifiche del linguaggio ci dovrebbe essere una "migliore" soluzione a queste stranezze. Quindi sono molto curioso di sapere se ciò è dovuto all'ottimizzazione di Chrome oltre a Firefox. E anche se queste ottimizzazioni possono essere facilmente disabilitate durante lo sviluppo (forse dovrebbero essere disabilitate quando gli strumenti di sviluppo sono aperti?).

Inoltre, posso riprodurlo sia con punti di interruzione che con l' debuggeraffermazione.

Ho trovato un rapporto sul problema v8 che riguarda proprio quello che stai chiedendo.

Ora, per riassumere ciò che viene detto in quel rapporto sul problema ... v8 può memorizzare le variabili locali in una funzione nello stack o in un oggetto "contesto" che vive nell'heap. Allocerà le variabili locali nello stack purché la funzione non contenga alcuna funzione interna che si riferisca ad esse. È un'ottimizzazione . Se una funzione interna fa riferimento a una variabile locale, questa variabile verrà inserita in un oggetto di contesto (ovvero nell'heap anziché nello stack). Il caso di evalè speciale: se viene chiamato affatto da una funzione interna, tutte le variabili locali vengono inserite nell'oggetto contesto.

Il motivo per l'oggetto di contesto è che in generale è possibile restituire una funzione interna da quella esterna e quindi lo stack esistente durante l'esecuzione della funzione esterna non sarà più disponibile. Quindi qualsiasi cosa acceda alla funzione interna deve sopravvivere alla funzione esterna e vivere nell'heap piuttosto che nello stack.

Il debugger non può ispezionare quelle variabili che si trovano nello stack. Per quanto riguarda il problema riscontrato nel debug, un membro del progetto afferma :

L'unica soluzione che mi viene in mente è che ogni volta che devtools è attivo, eliminiamo tutto il codice e ricompiliamo con l'allocazione del contesto forzata. Ciò regredirebbe drammaticamente delle prestazioni con devtools abilitato però.

Ecco un esempio di "se una funzione interna fa riferimento alla variabile, inseriscila in un oggetto di contesto". Se si esegue questo sarete in grado di accedere xalla debuggerdichiarazione, anche se xviene utilizzato solo in foofunzione di, che non è mai chiamato !

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

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

  function bar() {
    debugger;
  };

  bar();
}
baz();

Come ha detto @Louis, causato dalle ottimizzazioni di v8. Puoi attraversare lo stack di chiamate per inquadrare dove è visibile questa variabile:

O sostituire debuggercon

eval('debugger');

eval eliminerà il pezzo corrente

L'ho notato anche in nodejs. Credo (e ammetto che questa è solo una supposizione) che quando il codice viene compilato, se xnon appare all'interno bar, non viene reso xdisponibile nell'ambito di bar. Questo probabilmente lo rende leggermente più efficiente; il problema è che qualcuno ha dimenticato (o non importava) che, anche se non c'è xin bar, si potrebbe decidere di eseguire il debugger e quindi ancora bisogno di accesso xdall'interno bar.

Caspita, davvero interessante!

Come altri hanno già detto, questo sembra essere correlato scope, ma più specificamente, correlato debugger scope. Quando lo script iniettato viene valutato negli strumenti di sviluppo, sembra determinare a ScopeChain, il che si traduce in una certa stranezza (poiché è legata all'ambito dell'ispettore / debugger). Una variante di ciò che hai pubblicato è questa:

(EDIT - in realtà, lo dici nella tua domanda originale, yikes, my bad! )

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();

Per l'ambizioso e / o curioso, cerca (eh) la fonte per vedere cosa sta succedendo:

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

Sospetto che ciò abbia a che fare con il sollevamento di variabili e funzioni. JavaScript porta tutte le dichiarazioni di variabili e funzioni in cima alla funzione in cui sono definite. Maggiori informazioni qui: http://jamesallardice.com/explaining-function-and-variable-hoisting-in-javascript/

Scommetto che Chrome sta chiamando il punto di interruzione con la variabile non disponibile nell'ambito perché non c'è nient'altro nella funzione. Questo sembra funzionare:

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

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

Come fa questo:

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

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

Spero che questo e / o il link sopra siano di aiuto. Queste sono le mie domande preferite su SO, BTW :)