595940 - eval doesn't parallel static restrictions

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Dave Herman [:dherman]]

We statically reject certain problematic cases like a var hoisting past a let:

    js> function foo() { { let x; var x; } }
    typein:15: TypeError: redeclaration of let x:
    typein:15: function foo() { { let x; var x; } }
    typein:15: ..............................^

but dynamically, this is still allowed:

    js> function foo() { { let x; eval("var x;") } }

This gets especially weird when you have initializers, since the var hoists outside the let, but the initializer mutates the let-bound variable.

    js> function foo() {
        var x = "untouched";
        {
            let x = "temporary";
            eval("var x = 'modified'");
            print(x);
        }
        print(x);
    }
    js> foo()
    modified
    untouched

How feasible would it be to parallel the static restrictions with dynamic restrictions inside eval code?

Dave

Comment 1

[Shu-yu Guo [:shu]]

A small thing to add: eval isn't aware of the let-scope at all:

    js> function foo() {
        {
            eval("let x = 'x'");     
        }
        print(x);
    } 
    js> foo();
    x

Comment 2

[Dave Herman [:dherman]]

> A small thing to add: eval isn't aware of the let-scope at all:

That's not accurate; eval is aware of the let-scope, but it converts its top-level lets into vars.

>     js> function foo() {
>         {
>             eval("let x = 'x'");     
>         }
>         print(x);
>     } 
>     js> foo();
>     x

What's happening here is that what looks like a let is actually a var, and so it creates a function-hoisted binding for x. But you really can see the let-bindings from eval:

    js> function foo() { { let x = "x"; return eval("x") } }
    js> foo()
    x

Dave

Comment 3

[Shu-yu Guo [:shu]]

Ah I see, it's aware in the sense that it can do lookups in the scope chain but it doesn't seem to know that it was called from within a let-scope and its let bindings should not be converted to vars.

Comment 4

[Dave Herman [:dherman]]

> it doesn't seem to know that it was called from within a let-scope and its let
> bindings should not be converted to vars.

I guess that "should" is subjective (and the idea that let should ever be turned into var is questionable in the first place), but that's the idea.

A little more precisely: "global" means "syntactically global to the script being eval'ed," not "in a singleton scope chain."

Dave

Comment 5

[Jason Orendorff [:jorendorff]]

I think shu has fixed this.