Block-level functions and web extensions about escope HOT 4 OPEN

The behavior of the compatibility semantics (as I understand it) is as follows:
When a function body is instantiated, it looks for functions declared in blocks inside of the body which could be replaced with var declarations of the same name without causing an early error. This replacement does not actually occur, but an additional binding may be created. Essentially this requirement means that the new binding may not conflict with any lexical bindings in the block's scope or any containing scope, up to and including the scope in which the function's parameters are declared.

For such functions, a var-scoped binding is created in the function body's scope, in addition to the lexical binding created in the block containing the function declaration. This additional binding is initially undefined. When the function declaration statement is executed, instead of the statement doing nothing (recall that function declarations are hoisted to the top of the containing block), the statement will fetch the value of the normal, lexical binding created by the declaration and set the additional var-scoped binding to that value.

This can can lead to some surprising behavior. For example, the following snippet prints 0 with no errors (per spec, although I'm not aware of any correct implementations at the moment):

(function(){
  {
    f = 0;
    function f(){};
  }
  console.log(f);
})();

Note also that there is currently a spec bug, which I just reported, which means that none of this will actually happen.

from escope.

It looks like a bug to me.

I guess escope should use this.currentScope().variableScope instead of this.currentScope() at this line: https://github.com/estools/escope/blob/master/src/referencer.js#L292

from escope.

Ah, there is a comment above the line...

from escope.

I don't think there's anything wrong with the current behaviour. Even if it may work while not being recognised by this tool, you should strife to write valid code that does not rely on being executed in a legacy environment anyway.
So if this feature should be built into escope, it should definitively be hidden behind a flag.

from escope.