Open Bug 691894 Opened 8 years ago Updated 5 years ago

Implement Environment.prototype.eval, .evalWithBindings

Categories

(Core :: JavaScript Engine, defect)

Other Branch
x86
macOS
defect
Not set

Tracking

()

People

(Reporter: jorendorff, Unassigned)

References

Details

No description provided.
This turned out to be something of a pain.

  - The front end isn't set up to handle compiling against a Call object.
    Only stack frames. This was pretty easy to fix.

  - ContextStack::pushExecuteFrame had to be rewired a bit to handle running
    against a Call object without a StackFrame. This was a bit touchy but I
    think I got it working.

  - It's impossible to recover the this-value for an execution context given
    only the lexical environment. The API is incomplete: the method should
    probably include a way to specify a this-value.

  - I am worried about DEFVAR and DEFFUN opcodes being emitted that could
    extend Call environments that the were previously assumed to be inextensible.
    I didn't try to fix this.

  - Deciding when to treat the eval code as strict mode (and thus introduce
    a new variable environment, like strict direct eval) turned out to be
    hard to specify nicely.

  - Need to do some more research to figure out how best to handle "arguments".
    ES5 says "arguments" is a binding in the call environment, but we don't
    actually implement it that way--at least, I *think* we never do.

And I have vague misgivings about adding another vector into the interpreter.

So this has been reclassified as a "future plan" for now. We may actually do it but it needs more thought than I can give it today.
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.