"eval" should not be able to change DontDelete-ness of a binding

[lth]

(Really Brendan's bee, not mine, but the atrocity should be fixed anyhow.)

This is legal in ES3:

var v
eval("function v() {}")
delete v

It is legal because the introduction of the function by eval replaces the DontDelete binding of v with one that is deletable.

From https://bugzilla.mozilla.org/show_bug.cgi?id=395868 we have the following:

"""Relevant sections of the spec are: 10.1.3 where it states: "... If the variable object already has a property with this name, replace its value and attributes", and 10.2.2 with "Variable instantiation is performed using the calling context's variable object and using empty property attributes"."""

[brendan]

Thanks for filing this. It's not just a bee in my bonnet, but yours too ;-).

See https://bugzilla.mozilla.org/show_bug.cgi?id=395868#c14 where Florian Loitsch reports that no browser implements what ES1-3 specify here. That makes this a clear "bug fix" in the "de-facto standard trumps de-jure standard" sense, never mind the problems this poses for ES4.

/be

[lth]

I agree this seems like a clear bug fix candidate.

[David-Sarah Hopwood]

Relevant to ES3.1.

[David-Sarah Hopwood]

So, if I understand this issue correctly, in the current ES3.1 draft:

Local variables are not normally deletable because they are described by "declarative environment records", and step 5b in section 11.4.1 just returns false from delete in this case.

For strict eval code, step 3 of section 10.4.2 creates a new declarative environment record for the eval'd code, and so it cannot affect any bindings in the enclosing function.

For non-strict eval code, steps 5 and 6 of "Declaration Binding Instantiation" in section 10.6 do not do anything for bindings that already exist in the enclosing function, and in particular they don't change the attributes.

So I think this bug is fixed. But someone else who understands how the new spec handles environments (which is very different from how ES3 handled them) should confirm that.

[David-Sarah Hopwood]

Based on the argument in my previous comment, I'm assuming this is fixed.