9.2.13 FunctionDeclarationInstantiation(func, argumentsList, env ) Abstract Operation
18.2.1.2 Runtime Semantics: EvalDeclarationInstantiation( body, varEnv, lexEnv, strict)
9.2.13 sets "topLex" in step 30, but default parameter expressions may contain direct eval expressions, that means when accessing "topLex" in 18.2.1.2 step 6.b won't be successful (it's value is still `undefined`).
Also: When parameter expressions are present, the execution context's "VariableEnvironment" is not a FunctionEnviroment, so the condition in 18.2.1.2 step 6.b is not fulfilled, but IIUC it needs to be to perform the lexical redeclaration checks.
I'd think we should scope direct evals in parameter list expressions the same as we do for strict direct evals -- all declaration get created in a new environment that is discard when the eval completes.
I'm going to start an es-discuss thread on this.
fixed in rev33 editor's draft
direct evals in parameter initializers now create their var bindings in their own scope, even if they aren't strict.
Because of that direct eval in an initializer won't access topLex and don't need to do the 6.b validation.
fixed in rev33 editor's draft
Actually, each parameter position gets one Var environment that is used by all of its direct evals:
So:
var x=0;",
function f(a=(eval("var x=1;"),eval("log(x)")),
b=eval("log(x)")
) {log(x)}
f();
should log: 1 0 0
fixed in rev33